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NEW OBJECT-ORIENTED LANGUAGE 


VehicleObj = OBJECT 

course: [ 0 .. 359 ]; 
speed: INTEGER; 
position: LOCType/ 

TELL METHOD ProceedTo(IN Dest: LocType); 
ASK METHOD Stop; 

END OBJECT; 

AircraftObj = OBJECT(VehicleObj,GraphicsObj); 
altitude: INTEGER; 

OVERRIDE 

ASK METHOD Stop; 

END OBJECT; 


MODSIM II — at last, a complete object-oriented language with built-in graphics 


MODSIM II — Now Available 
Object-Oriented Programming with Graphics 


Free trial and, if you act now, free training 


M ODSIM IFM is a modem, 

object-oriented language. All 
the features needed for programming 
with graphics are built-in. 

MODSIM II supports multiple 
inheritance and dynamic object crea¬ 
tion. Objects may redefine methods, 
and communicate through message 
passing. 

MODSIM II has the facilities you 
need to develop and maintain reusable 
code fdr large projects. Your programs 
can be divided into separately compiled 
modules, and common constructs can be 
imported from libraries that you define. 

Simulation constructs are built-in, if 
you need them. 

Easy-to-understand graphics 
Designing a graphical interface is 
simplified through the use of the 
SIMGRAPHICS IFM Graphics Editor. 

You see exactly what your graphics 
will look like - no struggling with 
graphics primitives. Your input forms 
can contain menu bars, buttons, and 
other powerful input tools. 

The graphs, icons, and input forms 
you’ve described using the Graphics 
Editor are connected directly to vari¬ 
ables and control code in your program. 


Free trial offer 

The free trial contains everything 
you need to try MODSIM II on your 
computer. Try the language, the quality 
and timeliness of our support, and our 
documentation and training — every¬ 
thing you need for a successful project. 

We’ve been providing software and 
support for 27 years - we’ll be here 
when you need us. 

Computers with MODSIM II 

MODSIM II is highly portable. It is 
already available for most popular com¬ 
puters. 

Charter User Group benefits 

CACI is now organizing a MODSIM 
II Charter User Group. Members 
receive a reduced price for MODSIM II, 
early releases, and other major benefits. 

For a limited time we also include 
free training. Call today to avoid disap¬ 
pointment — class size is limited. 

For immediate information 

In the U.S., call Hal Duncan at (619) 
457-9681, or Fax (619) 457-1184. In 
Europe, call Nigel McNamara in the 
UK, on (01) 332-0122, Fax (01) 332- 
0112. In Canada, call Francis Lobo at 
(613) 747-7467, Fax (613) 747-2224. 


Rush information on MODSIM II. 

Free trial - learn the reasons for the broad 
and growing popularity of MODSIM II. 

Charter User Group offer - return 
the coupon today and we will include a 
free course enrollment worth $950. 
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18 The Monarch Parallel Processor Hardware Design 

Randall D. Rettherg, William R. Crowther, Philip P. Carvey, and Raymond S. Tomlinson 
The Monarch architecture team took advantage of custom VLSI in the design of a shared-memory parallel processor. 
The simple structure eases the task of programming a massively parallel machine. 
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An Introduction to the Multimesh Graph Method 

Jaime H. Moreno and Tomas Lang 
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The multimesh graph method for deriving these arrays is systematic, flexible, and easy to use. 
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Lui Sha and John B. Goodenough 

Rate monotonic scheduling theory puts real-time software engineering on a sound analytical footing. 
Here, we review the theory and its implications for Ada. 
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Alan Jay Smith 

Computer researchers have a professional obligation to referee the work of others. 
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74 Fundamentals of Bar Code Information Theory 

Theo Pavlidis, Jerome Swartz, and Ynjiun P. Wang 

To compare encoding and decoding schemes requires us to first look into information and coding theory. 
This article discusses problems and possible solutions in encoding information. 
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Computer Society Board of Governors’ response to 
IEEE reorganization proposal 


D uring 1989 the IEEE Board of 
Directors was asked to consider 
several actions that would reor¬ 
ganize the institute’s volunteer structure. 
The IEEE Board created an ad hoc com¬ 
mittee to study the matter and make a 
recommendation. That committee re¬ 
ported to the board late last summer with 
a proposal for sweeping changes in the 
IEEE organization. The Board of Direc¬ 
tors received the report and invited com¬ 
ment from all entities within the institute 
before taking any action. 

The Computer Society Board of Gov¬ 
ernors considered the proposal at length 
at its November 17, 1989, and March 2, 
1990, meetings and adopted a position 
statement at its March meeting. This 
statement has been transmitted to the 
IEEE volunteer leadership. 

The board’s position is that the pro¬ 
posed reorganization is too radical a so¬ 
lution to the minor problems identified, 
and is not in the best interests of the in¬ 
stitute or the society. The society’s posi¬ 
tion statement is reproduced here in its 
entirety so that society members may be 
fully informed on this potentially signifi¬ 
cant proposal. (Other actions taken by the 
Computer Society’s Board of Governors 
at the March 2 meeting will be reported 
in the May issue of Computer, along with 
coverage of Compcon Spring 90.) 

Helen M. Wood 
Computer Society president 


n its recent acceptance and approval 
in concept of the report of ah ad 
hoc committee on volunteer reor¬ 
ganization, the Board of Directors of the 
IEEE recognized that such sweeping 
changes would have a profound effect on 
the future of the institute. It therefore 
moved to encourage discussion at all lev¬ 
els, and to “invite comments from all 
interested parties and groups.” This 
statement is the response of the IEEE 
Computer Society to that invitation. 

There are many facets of the proposed 
reorganization, but the society chooses to 
comment on only four: national entities 
and the international character of the in¬ 
stitute, lEEE-USA as a special case, 
standards, and educational activities. 

National entities and 
IEEE’s international 
character 

One of the great strengths of the IEEE 
has been its international scope. It is rec¬ 
ognized throughout the world as the ma¬ 
jor professional association in the field 
of electrotechnology. As the Computer 
Society has expanded its own interna¬ 
tional activities, especially with the crea¬ 
tion of its overseas offices in Brussels 
(1985) and Tokyo (1988), we have found 
the identity of the IEEE to be a critical 
door-opener and contributor to our ac¬ 
ceptance and success. Still, when ap¬ 


proaching national societies in Europe 
and Asia, we find some initial hesitancy. 
There is a fear that this IEEE colossus 
will somehow overwhelm the inevitably 
smaller and possibly weaker national so¬ 
ciety, stealing all its members and sup¬ 
planting its publications and conferences. 
Society leaders have dealt with these 
fears diplomatically, emphasizing that 
our intent is first to better serve our 
members, but also to seek cooperative 
activities with the national societies — 
activities that could benefit both their 
members and ours. Progress is slow, but 
encouraging. But should these national 
societies suddenly find themselves con¬ 
fronted with an lEEE-Belgium, or lEEE- 
Australia, the reaction will be swift and 
predictably negative. 

Where there is a strong national soci¬ 
ety or societies with technical interests 
similar to the IEEE or some of its units, 
there is clearly no need for a redundant, 
competing entity established by the 
IEEE, either from the perspective of the 
professionals in that country or from the 
perspective of the IEEE. The national 
society meets the needs of the former 
group, and any institutional needs of the 
IEEE can be adequately met by the ro¬ 
bust RAB [Regional Activities Board] 
structure, and by chapters affiliated with 
the TAB [Technical Activities Board] 
societies. Where such national societies 
do not exist it seems arrogant, reflecting 
a kind of colonialist attitude, for the 
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IEEE to presume to create one under its 
structure and in its own image. Rather, 
the IEEE should make its resources 
available to help local professionals cre¬ 
ate their own organization, and seek to 
support it through cooperative activities 
during its formative years. 

The position of the IEEE Computer 
Society is that the creation of geographic 
entities of the type proposed is unneces¬ 
sary to the future success of the IEEE 
and inappropriate to its dealings with the 
world’s professional societies. 

lEEE-USA: A special case 

One national entity already exists 
within the IEEE, the United States Ac¬ 
tivities Board (USAB), currently styled 


The creation of a second 
IEEE president as proposed 
would indisputably reduce 
the stature of the IEEE 
presidency. 


as lEEE-USA. A primary consequence of 
the proposed changes is to substantially 
enhance the organizational stature of that 
body, making it essentially parallel to the 
IEEE itself. We view this as not only un¬ 
necessary, but highly undesirable. USAB 
is one of several program boards with 
specific responsibilities for individual in¬ 
stitute programs. In this case, those pro¬ 
grams are specifically addressed as US 
issues, ranging from professional con¬ 
cerns of individual members, such as 
pensions, to major policy concerns such 
as support for supercomputing research. 
The reorganization proposal does not 
identify any convincing barriers to the 
success of USAB in carrying out its mis¬ 
sion which are posed by the current or¬ 
ganizational structure. It is not clear that 
increased autonomy, referenced fre¬ 
quently in the committee report, is in re¬ 
sponse to constraints on the actions of 
USAB. Rather, the impression is that 
what is being sought is increased stature, 
at the expense of the IEEE. For example, 
the creation of a second IEEE president 
as proposed would indisputably reduce 
the stature of the IEEE presidency. Con¬ 
trolled only by the IEEE board’s ap¬ 
proval of bylaw changes, it effectively 
becomes autonomous. And despite all 
this, it still would not be the national so¬ 
ciety for US electrical, electronics, and 
computer engineers and computer scien¬ 
tists. Professional societies for technical 
professions must, at base, be primarily 
technical in their orientation. An organi¬ 


zation oriented to public policy issues 
and divorced from the technical societies 
can never be the whole association im¬ 
plied by the lEEE-USA label. 

An alternative approach through which 
the USAB could productively increase its 
autonomy and stature is to develop its 
programs in response to the needs of its 
own members. Currently USAB has no 
self-selected membership base. The in¬ 
voluntary assessments of all IEEE mem¬ 
bers who happen to live in the United 
States does not automatically provide 
such a constituency. If USAB were oper¬ 
ated in a manner analogous to the socie¬ 
ties, it would have a clear constituency. 

Its membership would be US technical 
professionals who have chosen to sup¬ 
port its activities by paying optional 
dues. As a society-like organization, it 
could have its own president and board, 
and operate with very considerable au¬ 
tonomy under the current IEEE organiza¬ 
tion and rules. And the direct tie of in¬ 
come to satisfied members assures that 
its programs will stay accurately focused 
on member needs. 

The position of the IEEE Computer 
Society is that a separate, parallel lEEE- 
USA should not be created as proposed, 
and that other means of addressing its le¬ 
gitimate needs be addressed, such as or¬ 
ganizing the current USAB on a techni¬ 
cal society model. 

Standards 

The organizational relocation of IEEE 
standards activities under the umbrella of 
a US-oriented structure is a very bad 
idea. Most of our standards activities are 
not addressed at the development of 
purely American standards. Rather, the 
intention is to develop IEEE standards 
which we hope will become international 
standards. That they may be adopted as 
ANSI standards along the way is good, 
but ultimately irrelevant. Increasingly, it 
is recognized that widely accepted inter¬ 
national standards are one of the best 
paths to true global competitiveness. Na¬ 
tional standards are more likely to create 
barriers. The Computer Society has a di¬ 
rect stake in this issue. Through our stan¬ 
dards development efforts (currently 
over 190 standards and projects), the 
IEEE is emerging as one of the primary 
players in the international computer 
standards arena. Standards are by their 
nature technical, requiring the best con¬ 
temporary thought and analysis of diffi¬ 
cult technical issues. The strength of the 
IEEE standards programs is that they are 
grounded in the technical societies. The 
credibility of the outputs, increasingly 
positive relative to trade association- 
based standards activities, is due to our 


provision of a level playing field for all 
interested parties, where the best techni¬ 
cal solutions may be sought without re¬ 
gard to nationality. To attempt to manage 
standards development activities di¬ 
vorced from the technical societies is 
clearly misdirected. 

The Computer Society has an extraor¬ 
dinarily robust standards development 
program, addressing both hardware and 
software problems, and involving thou¬ 
sands of member volunteers. And these 
are not just US members. What is likely 
to be one of our most successful bus 
standards, Futurebus (896), was first 
adopted by the US Navy, yet the chair of 
the working group which developed that 
standard was a citizen of the UK. There 
are many non-US participants in our 
working groups, sometimes comprising 


In today’s global economy, 
national standards are 
increasingly 
anachronisms and 
barriers to free trade. 


20 percent or more of the members. 
Working group meetings are routinely 
held throughout the world. There are in¬ 
creasing demands for translation of our 
standards into other languages. Many 
more specifics could be cited, but the 
point is clear. In today’s global econ¬ 
omy, national standards are increasingly 
anachronisms and barriers to free trade. 
Placement of the IEEE standards develop¬ 
ment activities under a US-oriented 
board would be a step backward. 

This is not to say that there are not le¬ 
gitimate US issues in the standards 
arena. Just as international standards fos¬ 
ter global competitiveness, US involve¬ 
ment in the development, promulgation, 
and adoption of those standards can en¬ 
hance American competitiveness. It is 
quite Appropriate for the USAB to ad¬ 
dress such issues, but not to manage the 
standards development effort. 

The position of the IEEE Computer 
Society is that the management of IEEE 
standards development activities should 
remain with a central standards board 
which operates in close cooperation with 
the technical societies, and that national 
standards policy for the United States is 
an appropriate subject for USAB consid¬ 
eration. 

Education 

Another part of the proposal under 
consideration is to move the institute’s 
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Software 

Engineering 


From Theory 


Software Engineering 

Methods and Management 

Anneliese von Mayrhauser 

This book is a solid intro¬ 
duction to the field of soft¬ 
ware engineering, covering 
a wide range of topics. It is 
intended as a primary text¬ 
book for a two-semester 
course sequence on software 
engineering in a computer 
science curriculum. The first 
course teaches methods and 
techniques for developing 
software, and a second in¬ 
troduces the student to the 
management of software engineering projects. While 
intended for courses at the upper undergraduate or 
first-year graduate level, this book is a reliable hand¬ 
book of software engineering for the practicing 
professional. 

March 1990, 896 pages, $49.95/ISBN: 0-12-727320-4 


To Practice 


Software That Works 

Michael Ward 

Why do some software projects succeed while others 
fail—even when the same people are involved? Is 
software development an art, a science, or a little of 
both? Can software development really be “managed”? 
This book delivers the answers to these and other vital 
questions dealing with software development. Drawing 
upon his years of experience, Michael Ward gives a 
“real world” view of how software is developed and 
tested. 

June 1990, c. 385 pages, $39.95 (tentative) 

ISBN: 0-12-735040-3 



ACADEMIC PRESS 

Harcourt Brace Jovanovich, Publishers 
Book Marketing Dept. #26040,1250 Sixth Ave., San Diego, CA 92101 


CALL TOLL FREE 

1 - 800 - 321-5068 

Fax: (314) 528-5001 

Quote this reference number for free postage and handling 
on your prepaid order»» 26040 


accreditation-related activities under the US organizational 
unit. Because such a proposal could logically be made regard¬ 
ing USAB even if, as we recommend, the proposed lEEE-USA 
is not created, the Computer Society wishes to address the is¬ 
sue. This issue is more subtle than the others. IEEE accredita¬ 
tion activities are ultimately expressed through the Accredita¬ 
tion Board for Engineering and Technology (ABET). A com¬ 
mittee structure has been established under the lEEE-EAB 
[Education Activities Board] which funnels IEEE concerns to 
ABET. Those committees enjoy a rich relationship with the 
IEEE technical societies through the participation of volunteers 
representing the technological gamut. Indeed, the IEEE Com¬ 
puter Society has had an especially productive relationship with 
these bodies through the years, and society leaders have held 
many offices on these committees and through them in ABET 
bodies themselves. This is in addition to the society’s participa¬ 
tion, as a partner with ACM, in the Computing Sciences Ac¬ 
creditation Board (CSAB). The elaborate EAB structure has 
been built up over the years in part to protect the accreditation 
process from short-term fashion and the intrusion of other, 
noneducational issues. In so doing, ABET has become the envy 
of the world in technical accreditation. While it is true that its 
formal accreditation practice is generally limited to the US, 
ABET has accredited programs outside the US that are affili¬ 
ated with US colleges and universities. In addition, ABET fre¬ 
quently consults with similar organizations in other countries 
and has established reciprocal relationships with some, benefit¬ 
ing all our members throughout the world. The lEEE-EAB/ 
ABET process is working extremely well. There is no reason to 
disturb this productive but potentially fragile mechanism. 

The position of the IEEE Computer Society is that the IEEE 
accreditation activities involving ABET remain unchanged. 
However, should the current EAB structure be dissolved for 
other reasons, the existing accreditation structure, in toto and 
unchanged, should be placed organizationally under lEEE- 
TAB. 


Summary 

Many of the comments on the proposals that the board has 
seen on Compmail-f- or elsewhere seem to come down to the 
old bromide. If it ain’t broke, don’t fix it. We agree. It is obvi¬ 
ous that many, maybe most, of our programs and organizational 
structures could be improved, but the proposal did not address 
any problem that merits so drastic a fix. It set forth the general 
goal of strengthening the international character of the IEEE. 
The IEEE is the world’s foremost international technical pro¬ 
fessional society — the biggest and the best! To be sure, there 
are things we can do to better serve our members world-wide. 
Opening non-US IEEE offices as is currently under considera¬ 
tion is one way to do that. Working through the societies to fos¬ 
ter relationships with national societies in their technical spe¬ 
cialties to bring workshops and conferences to more places is 
another. But fundamentally, the current international character 
of IEEE is an existing strength upon which to build the future. 

The core of the proposal seems to be the enhanced status of 
USAB. By most accounts the USAB programs are substantial 
successes, so it is not obvious what is in need of repair here ei¬ 
ther. But to the extent that improvements are needed to further 
strengthen the USAB program, those improvements should be 
targeted precisely at the specific problem or objective. What¬ 
ever the perceived potential benefit, the fundamental reorgani¬ 
zation of a highly successful structure entails far too high a 
price, and could irreversibly weaken or destroy key programs 
upon which the very reputation of IEEE has been built. 
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Al^s Ada ODSS-CQmpiters 
^t\ou there inno time. 



It’s time you knew that 
Alsys, the premier Ada company, 
offers a range of powerful and 
flexible cross-compilers for all 
microprocessors in the Motorola 
MC680X0 and Intel i80X86 
families* to get your applications 
up and running fast. 

I^rt of the reason for this 
speed are powerful development 
tools such as AdaProbe, a source 
level debugger and program 
viewer providing facilities to 
address both the execution prop¬ 
erties of a program and its static 
structure. In addition, there’s 
support for placing program 
components into ROM, and the 
Alsys Multi-Library Environ¬ 
ment allowing pro^am units to 
be shared among libraries for 
team programming. 

With Alsvs’ full line of 
cross-compifers you’ll discover 
impressive flexibility and power. 
There’s a configurable run-time 
system dving you full control 
over tasKS, interrupts and all 
components of your application. 
The debugger and transfer utility 
are confi^rable. Best of all, it’s 
easy to t^e advantage of all this 

f lower because there are only a 
iew files to modify. 

When you need to get from 
here to there without getting lost 
somewhere in between, use a 
cross-compiler that knows the 
shortest route. 



In the US; Alsys, 67 South Bedford Street. Burlington. MA 01803-5152, | 
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LETTERS TO THE EDITOR 


Parnas’ position praised, pilloried 


To the Editor: 

I would like to object to the article by 
David Lorge Parnas that appeared in the 
January 1990 issue of Computer [“Edu¬ 
cation of Computing Professionals,” pp 
17-22]. In my seven years as a working 
professional in the computer field, I have 
found myself and others with CS degrees 
to be at least as able to function as those 
with other degrees. I have never found 
employers to be reluctant to hire us. To 
me, it appears that CS graduates actually 
have more employment and self-employ¬ 
ment opportunities than engineering 
graduates. 

I am very disturbed that the Computer 
Society published an article full of state¬ 
ments about the incompetence of com¬ 
puter scientists. The Computer Society 
claims to “build up” the profession. You 
may as well publish a full page ad advis¬ 
ing companies to “avoid hiring our mem¬ 
bers.” 

In my seven years as a member, I have 
never been very happy with the Com¬ 
puter Society. Now I wonder why 1 am 
paying you $47 [1990 US affiliate mem¬ 
ber dues] to harm my career. Every year, 
I debate renewing my membership and 
finally give in. Unless I see some type of 
retraction, or equal time for opposing 
viewpoints, my membership will end this 
year. 

Grace McGonnigal 

Laurel, Maryland 


To the Editor: 

The article “Education for Computing 
Professionals” in the January 1990 issue 
of Computer exposed some very real 
weaknesses of the current computer sci¬ 
ence curriculum. The courses proposed 
were remarkably similar to those I re¬ 
ceived by taking two years of electrical 
engineering before switching to com¬ 
puter science. I feel my CS education 
was much stronger as a result. 

However, I am concerned that the pro¬ 
posed curriculum will alienate a large 
group of students who are already alien¬ 


ated by the existing engineering disci¬ 
plines, namely, women and ethnic mi¬ 
norities. Current engineering programs 
assume a base experience that is heavily 
weighted to the white male background. 

Given the current problems with inner 
city schools, the limited resources of 
small rural schools, and the existing cul¬ 
tural attitudes that discourage girls from 
really learning math and science, it is un¬ 
reasonable to expect most women and 
ethnic minorities to cope with the cur¬ 
riculum Parnas proposes. One solution is 
to provide remedial classes and “head 
start” summer sessions as is currently 
done for other engineering disciplines at 
some universities. A better solution 
would be to change the current attitudes 
that assume the white-suburban-male ex¬ 
perience is the only background appro¬ 
priate for an engineering student. 

Sarah Hancock 

Somerville, Massachusetts 


To the Editor: 

With over a decade in software con¬ 
sulting, and also having taught under¬ 
graduate CS, I can personally corrobo¬ 
rate and expand on Parnas’ position that 
CS needs to be taught as more of an en¬ 
gineering discipline. A large part of my 
work consists of revising code for 
greater performance and/or maintainabil¬ 
ity. Much of this would be unnecessary if 
programmers had more of a quantitative, 
scientific understanding of what they do. 

In terms of performance, CS graduates 


Computer welcomes your letters. 

Send technical correspondence 
to Editor-In-Chief Bruce D. Shriver, 
Vice President for Research, Uni¬ 
versity of Southwestern Louisiana, 
PO Drawer 42730, Lafayette, LA 
70504-2730. Send other comments 
to Letters Editor, Computer, 10662 
Los Vaqueros Circle. PO Box 3014, 
Los Alamitos, CA 90720-1264. 

All submissions are subject to ed¬ 
iting for styie, length, and clarity. 


know, in an intellectual sense, that dif¬ 
ferent data structures exhibit different 
big-O performance curves, and that there 
are points where the curves cross over, 
such that simpler techniques are faster at 
small table sizes. They know this, but 
they don’t put it into practice. They tend 
to use the most “sophisticated” technique 
and completely skip the analysis. It may 
be hard to believe, but it is routine to 
speed up some of this code by one to two 
orders of magnitude. It shouldn’t be hard 
to teach young software engineers to 
avoid this degree of waste, and industry 
would certainly be grateful. 

Software maintenance should be no 
mystery either; it’s not as though it’s 
hard to find examples of it. In my experi¬ 
ence, typical code can be improved in 
maintainability by factors from 2 to 10. 
Here again, it shouldn’t be hard to teach. 
I can imagine a project course in which 
student teams are given, halfway through 
the course, a list of a few dozen “unfore¬ 
seen” changes to make, some minor, 
some major. Let them compete on the 
basis of person-hours and correctness, 
and let the style take care of itself. 

Mike Dunlavey 

Needham, Massachusetts 


To the Editor: 

I would like to comment on David Par¬ 
nas’ piece, “Education for Computing 
Professionals.” I think it is unrealistic in 
three respects: 

First, the number of courses. If those 
courses for which Parnas did not specify 
a number of semesters were one-semes¬ 
ter courses, his suggested curriculum 
would require between 28 and 33 classes. 
Assuming that the classes were worth 
four units each, Parnas’ curriculum 
would account for at least 112 of the 
120-132 total units typically required for 
graduation. In addition, when I went to 
university, my school (UC Berkeley) re¬ 
quired of all students: two semesters of 
English, one semester of US history, 
three semesters of a foreign language, 
and one semester of a biological science. 
Something has to give. 

Second, the lack of a beginning pro¬ 
gramming course. Notwithstanding what 
Parnas remembers from long ago, in 
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1965 the Engineering College at 
Berkeley required all engineering stu¬ 
dents to take a beginning programming 
class. An identical class was taught in 
the Mathematics Department. No such 
class was taught in the Computer Science 
Department because there was no Com¬ 
puter Science Department. Computers 
are a lot more complex and capable than 
slide rules (this was before electronic 
calculators). 

Third, the lack of courses where the 
students write “big” programs. It is true 
that students never write really big pro¬ 
grams, and it is true that the feedback 
they receive is often inadequate. But, 
writing only small programs, as Pamas 
recommends, also leads to some “very 
bad education.” The students are led to 
believe that all programs are small pro¬ 
grams — a misconception much beloved 
by academics. Besides, semester-long 
programming projects are analogous to 
lab work in engineering or the physical 
sciences. They are essential. 

Bruce Walker 

San Pedro, California 


To the Editor: 

The article by David Lorge Pamas in 
the January issue of Computer, “Educa¬ 
tion for Computing Professionals,” 
makes the very worthwhile plea for shift¬ 
ing the curriculum emphasis to more fun¬ 
damentals and away from esoteric fads. I 
strongly endorse this sentiment, but to 
argue more convincingly, I would like to 
point out some more reasons for the pres¬ 
ent condition. 

The current emphasis on esoteric 
originality is the result of a natural need 
for the new field of computer science to 
create its own niche. In the struggle for 
academic survival, it is more important 
to be different from the existing depart¬ 
ments than it is to contribute something 
relevant. This is simply a social exten¬ 
sion of Darwin’s notion of speciation. 

At a time when the Swedish and Japa¬ 
nese have demonstrated the advantage of 
worker involvement with the entire prod¬ 
uct, we have created the entirely artifi¬ 
cial specialization of the software devel¬ 
opment life cycle. When capable soft¬ 
ware developers were in short supply, we 
tolerated the prima donnas who couldn’t 
be bothered with the more mundane 
phases. Now, successful organizations 
recognize that their survival depends on 
a high-quality product, which, in turn, is 
greatly enhanced by individual responsi¬ 
bility (and accountability) through the 
entire life cycle. 

With this understanding, I would like 
to go one step farther than Pamas and 


suggest some more practical courses. 
These courses address the extent to 
which computer science is influenced by, 
and influences, other fields, which is, af¬ 
ter all, the essential characteristic of our 
field today; 

(1) Real-time systems (process con¬ 
trol, movement control, continuous 
monitoring, on-line transaction process¬ 
ing) 

(2) Graphics/computer-aided design/ 
man-machine interface 

(3) Decision support systems 

(4) Public policy and professional pol¬ 
icy (copyright, privacy, fraud, federal 
funding, balance of trade, patent protec¬ 
tion, standards) 

To those who object that I have 
strayed from education into training, I 
offer as a reminder the examples of Rus¬ 
sia and Eastern Europe, which have been 
outstanding in theoretical computer sci¬ 
ence but woefully inadequate in the pro¬ 
duction and use of computers. 

Peter Gottlieb 

Los Angeles, California 


Pamas’ reply 


I am pleased, and not surprised, that 
Grace McGonnigal feels that she got a 
sound education and that she has found 
satisfying employment. Neither she nor I 
can ever know how her career would 
have progressed if she had received an 
engineering education. I am, however, 
disappointed that she does not recognize 
the value of free, and open, exchange of 
opinions. In contrast to McGonnigal, I 
cancel subscriptions to magazines if they 
never publish ideas with which I can dis¬ 
agree. 

I have great sympathy for the views 
expressed by Sarah Hancock. The prob¬ 
lem is quite real and should concern us 
all. Many people are poorly prepared for 
engineering by their elementary and sec¬ 
ondary educations. Women, and mem¬ 
bers of certain minority groups, may not 
have the role models that helped many of 
us find science and engineering careers. 
However, I believe that the correction 
must be made long before university. It 
is no service to either society or the stu¬ 
dent to reduce the level of rigor in uni¬ 
versity to compensate for deficiencies in 
earlier preparation. Extra preparation for 
those who have been deprived is the only 
solution that I can accept. 

Mike Dunlavey makes a number of 
statements with which I am quite sympa¬ 
thetic. However, for perspective, we 
should remember that there are few prod¬ 


ucts of any kind that cannot be improved 
by someone who has the advantage of 
seeing his predecessors’ mistakes and 
has time to study and rethink the issues. 
None of us does work that cannot be im¬ 
proved by someone else. 

Bruce Walker suggests that the num¬ 
ber of courses in my proposal is too 
large. I developed my proposal by re¬ 
placing courses in a fairly standard engi¬ 
neering curriculum with those that I 
thought more appropriate for computing 
professionals. The resulting curriculum 
is not bigger than the original, but, like 
all educational programs, it is full of 
compromises. He points out that, in 
1965, Berkeley demanded a program¬ 
ming course. Things have changed since 
1965, and most students arrive at univer¬ 
sity with extensive programming experi¬ 
ence obtained in high school or with 
home computers. While these experi¬ 
ences do not give them much insight 
about programming methods or seman¬ 
tics, it means that we do not have to 
spend time teaching them how to ap¬ 
proach and use the machine. Finally, 
Walker suggests that semester-long proj¬ 
ect courses are the analog of the labora¬ 
tory courses used in classical engineer¬ 
ing. In my experience, lengthy program¬ 
ming projects do not correspond to the 
carefully designed and controlled labora¬ 
tory experiences that were part of my 
engineering education. Further, as “big 
program” experience, courses are unreal¬ 
istic and misleading. A student’s limited 
time in university should not be used to 
do something that can be done better in a 
real work situation. Students who want 
to obtain experience with large programs 
during their education would be well ad¬ 
vised to participate in a “co-op” program 
that makes sure that the experience 
gained in the work-terms is coordinated 
with the education received in courses. 

While I agree with Peter Gottlieb on 
many points, I must view his four pro¬ 
posed courses in the light of Walker’s 
comments that my proposal already in¬ 
cludes too many courses. Although each 
of Gottlieb’s courses would be useful, I 
would be concerned if it displaced a 
more fundamental course. I am also not 
happy with the “anti theory” tone of his 
last paragraph. It is not wrong to teach 
theory; it is wrong not to teach how to 
use that theory. Often there is an unrea¬ 
sonable gap between theoretical and 
practical courses. It is vital that the fun¬ 
damental ideas taught in theory courses 
be used in the more practical parts of a 
student’s education. Sound practice must 
be based on sound theory. 

David L. Pamas 

Queen’s University 

Kingston, Ontario, Canada 


April 1990 








Chief's MESSA0E 


The benefits of quality refereeing 


Computer publishes manuscripts deal¬ 
ing with all aspects of computer science, 
engineering, technology, and applica¬ 
tions. It is aimed at a broad audience. Ar¬ 
ticles in Computer are often surveys or tu¬ 
torials covering the state of the art or im¬ 
portant emerging developments. Com¬ 
puter is referenced extensively in the lit¬ 
erature, and one of its important purposes 
is to act as a technology transfer conduit 
to bring results and formalisms from uni¬ 
versity, industry, and government re¬ 
search and development centers to gen¬ 
eral practitioners in the field. 

I am taking advantage of the fact that 
Alan Smith’s article on refereeing ap¬ 
pears in this issue to publish the Guide¬ 
lines for Referees, the Guidelines for Au¬ 
thors, and the forms that referees use 
when evaluating a manuscript for poten¬ 
tial publication in Computer. I receive a 
number of inquiries each month about 
these guidelines, and I thought their occa¬ 
sional open publication might encourage 
submissions to the magazine as well as 
additional volunteers to act as referees. 

Those of you who have written techni¬ 
cal articles know from experience how 
much time and effort it takes to develop a 
manuscript that is both readable and tech¬ 
nically relevant. You also know how im¬ 
portant a good, detailed review is in im¬ 
proving its overall quality and utility. 

During 1989, a significant number of 
people gave freely of their time and tech¬ 
nical expertise to referee manuscripts 
being considered for publication in Com¬ 
puter. Additionally, the Editorial Board 
members and department editors have 
given an extraordinary amount of their 
time to maintaining the high standards I 
have set for the magazine. 

I do not take the refereeing of manu¬ 
scripts lightly. Typically, a manuscript 
submitted to Computer is sent for review 
to six people who are actively working in 
the topic area, as well as to a referee or two 
representing the general audience per¬ 
spective. Guest editors and I expect refe¬ 


rees to make constructive, detailed com¬ 
ments that will help the author(s) to 

(1) correct errors and misconceptions; 

(2) state appropriate, accurate, and 
relevant conjectures and results; 

(3) employ better definitions, dia¬ 
grams, tables, graphs, and ex¬ 
amples; 

(4) use a minimum of contemporary, 
relevant, and essential references; 

(5) make the article technically con¬ 
sistent and complete; and 

(6) organize the material to help the 
reader understand the issues pre¬ 
sented. 

If a referee does not cover at least sev¬ 
eral of these issues, I usually reject the re¬ 
port. I then submit the manuscript to addi¬ 
tional reviewers, just as I do if the referees 
give conflicting views. We expect a 
strong consensus to publish a manuscript 
before accepting it. 

Doing this type of detailed, insightful 
referee’s report takes time and effort, but 
the payoff — publication of technically 
substantive, timely articles — benefits 
Computer's entire readership. Thus, hav¬ 
ing technically responsible referees is 


Computer referees, June 

Per-Tore Aasestrand, C-Three Systems 
Bruce Ableidinger, Cadre Technologies 
Norman Abramson, Univ. of Hawaii 
Stuart J. Adams, C.S. Draper Lab 
Sadashiv Adiga, Univ. of Calif., Berkeley 
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Dharma P. Agrawal, North Carolina State Univ. 
David W. Allen, Westinghouse Elect. 

Dennis R. Allison, Stanford Univ. 

Guy T. Aimes, Rice Univ. 

J. Wayne Anderson, Los Alamos National Lab 
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critically important to the magazine’s 
livelihood. 

Completing the review can be a lengthy 
process. Some manuscripts have been in 
this process for over a year (counting time 
for author revisions, which are also 
placed in review), but the majority of 
manuscripts complete the process in four 
to six months. This is an enviable record 
considering the standards employed and 
number of people involved. 

Please take time to review the guide¬ 
lines that appear on pages 14-15 as well as 
the refereeing forms. If you would like to 
be a part of this worthwhile endeavor, 
please circle number 190 on the Reader 
Service Card or send me your name, ad¬ 
dress (both physical and electronic), 
phone number, subject area (according to 
the Computing Reviews Classification 
System), and number of articles per year 
you can review. 

I acknowledge and thank the referees 
(listed below and on the following 
pages), my Editorial Board, and my de¬ 
partment editors for their efforts on Com¬ 
puter's behalf. 

Bruce D. Shriver 

Computer editor-in-chief 


1,1989-January 17,1990 
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Guidelines for Referees 

October 1989 


Computer covers all aspects of computer 
science, engineering, technology, and ap¬ 
plications. It is aimed at a broad audience. 
Computer publishes technically substan¬ 
tive articles that are referenced extensively 
in the literature. Articles in Computer are 
often survey or tutorial in nature and cover 
the state of the art and important emerging 
developments. One of the important pur¬ 
poses of Computer is to act as a technology 
transfer conduit to bring results and formal¬ 
isms from university, industry, and govern¬ 
ment research and development centers to 
the general practitioners in the field. 

All articles should be comprehensible to 
readers actively working in a technical dis¬ 
cipline. Insofar as possible, manuscripts 
should be written in a style similar to that of 
articles appearing in Scientific American. 

Refereeing reports should be returned on 
the Computer Review Form. Because Sec¬ 
tion II (Overview) and Section III (Detailed 
Comments) of the review form and the 
marked up manuscripts will be sent to the 
author(s) as they are, it is important that no 
identification of the referee should appear 
on them. Inappropriate remarks will be de¬ 
leted before any material is sent to the 
author(s). 

It takes a good deal of time and effort to 
develop a manuscript that is technically 
relevant and readable. A detailed review of 
a manuscript can be an invaluable aid to the 
author(s) in improving its overall technical 
quality, utility and readability. Please pro¬ 
vide constructive comments that will help 
the author(s) to 

(1) correct errors and misconceptions; 

(2) state appropriate, accurate, and 
relevant conjectures and results; 

(3) employ better definitions, dia¬ 
grams, tables, graphs, and examples; 

(4) use a maximum of 12 contemporary, 
relevant, and essential references; 

(5) make the article technically consis¬ 
tent and complete; and, 

(6) organize the material to help the 
reader understand the issues pre- 

Section II of the review form can be com¬ 
pleted using check marks. However, your 
detailed technical comments, written on 
the manuscript and summarized in Section 
m, are of far greater importance to the 
author(s) than the check marks. 

If major revisions are recommended, you 
should point these out as specifically as 
possible and should differentiate optional 
changes from those you judge mandatory. 

If the revisions required are extensive, it is 
perhaps best to reject the paper and recom¬ 
mend preparation of a new, heavily revised 
manuscript for resubmission to Computer. 
If you reject the manuscript mainly on the 
basis of reader interest, please suggest a 
more appropriate journal to the author(s). 


REVIEW FORM COMPUTER 


Date sent:_ Please return form and manuscript to: 

Bruce D. Shriver 

Date to be returned: __ Editor-in-Chief, Computer 

Vice President for Research 

Name and address of referee: Univ. of Southwestern Louisiana 

Drawer 42730 
Lafayette, LA 70504-2730 
Express Mail: 

Rougeou Hall, Rm 225 
241 E. Lewis St. 

Lafayette, LA 70503 
Internet: shrivertffiusl.edu 
Phone: (318) 231-5811 

Fax: (318) 265-5472 

Paper no:_ Revision no:_ 

Author(s):_ 

Title of paper:_ 


In accordance with the Guidelines for Referees, please complete the following review form. 

Section I is for the editor only; Sections II and III will be sent to the author(s). 

Section 1. Summary and Recommendation 

Summary of evaluation 

_Award quality _Excellent _Good _Fair _Poor 

Recommendation 
_Accept with no changes 

_Accept if certain minor revisions are made (see Section III) 

_Author should prepare a major revision (see Section III) for a second review. 

(Not applicable if the paper in question is itself a major revision of a previously reviewed paper). 

If the paper is rejected for publication in Computer, the authors should; 

_Prepare a major revision and resubmit to Computer as a “new” paper 

_Submit to another publication: 

_Regard the paper as not publishable 


Date:- Signature of referee: _ 

The following two sections [see figure on facing page] will be sent to the author and hence 
no identification of the referee should appear in these sections. Inappropriate remarks in these 
sections will be deleted or modified by the editor before these sections are sent to the author(s). 


First page of Computer Review Form. Only Sections II and III (facing page) are sent to the 
author(s) with the annotated manuscript, which gives the reviewer's specific comments. 
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I 


j Section II. Overview 

i Reader interest 

: 1. Is the paper of current interest to a reasonable segment of Computer’s readership? 

I _Yes _Perhaps _No 

1 2. Relative to the current level of reader interest in the paper, how is this interest likely to 

I change during the next five years? 

_Growing interest _Perhaps _Diminishing interest 

3. Within its particular field of specialization (as defined, for example, by the scope of a 
Computer Society technical committee), is the topic of the paper important? 

_Yes, definitely _Moderately so _Not really 

4. What percentage of the current entire readership do you estimate will 

(a) benefit from the article?_% (b) read the article?_% 

Content 

1. Is the paper technically sound? 

_Yes 

_Only partially (see Section in) 

2. Are the references or bibliography appropriate? 

_Yes _Some additions and/or deletions _No (see Section III) 

required 

Presentation 

, 1. Are the title and keywords appropriate? 

_^Yes _No (see Section III) 

2. Does the introduction clearly state the background and/or motivation in terms under¬ 
standable to the nonspecialist? 

_^Yes _Probably (see Section III) _No (see Section III) 

3. How would you rate the overall organization of the paper? 

_Satisfactory_Could be improved (see Section lU) _Poor (see Section III) 

4. Relative to its technical content and scope, is the length of the paper appropriate? (See the 
guidelines contained in the Information for Authors). 

_Yes _No, too long (see Section III) _No, too short (see Section HI) 

5. Is the English satisfactory? 

_Yes _No, but can easily be polished _No, very poor 

6. How readable is the paper for a Computer reader who is a nonspecialist in the field of this paper? 

_Readable with ordinary effort _Paper is self-contained, but a 

considerable effort is required 

_Difficult _Unreadable 

7. Disregarding technical content, how would you rate the quality of the presentation? 

I _ Excellent _ Good _Fair _Poor 


_ Appears to be, but didn’t check completely 

_No (see Section III) 


Second page of Computer Review Form. The reviewer summarizes his comments on 
page (see “Section III” at right). 


the third 


Manuscripts with little or no salvageable 
material should be rejected outright and 
later submission discouraged. 

Please use a pen with dark ink when you 
write comments on the manuscript and 
complete the review form. This will allow 
us to make readable copies of the material 
for our records. 

Do not copy the manuscript; return it 
with the review, since it is the property of 
the author(s). 

Return manuscript and report to: 

Bruce D. Shriver 

Editor-in-Chief, Computer 

Vice President for Research 

University of Southwestern Louisiana 

Drawer 42730 

Lafayette, LA 70504-2730 

Express Mail: 

Rougeou Hall, Room 225 
241 E. Lewis St. 

Lafayette, LA 70503 

Internet: shriver@usl.edu 

Phone: (318) 231-5811 
Fax: (318) 265-5472 


Section I. Summary and 
recommendation 

See figure at far left for a reproduction of 
this section. It is for the editor only and is 
not returned to the author(s). 


Section II. Overview 

See figure at left for a reproduction of 
this section, which is returned to the 
author(s). 


Section III. Summary of 
detailed comments 

Please make detailed technical and edi¬ 
torial comments and suggestions directly 
on the manuscript. Your comments are an 
invaluable aid to the author to help in im¬ 
proving the overall technical quality, util¬ 
ity, and readability of the material. Com¬ 
ments are not just useful, they are necessary 
to maintain the quality of the articles that 
are published in Computer. Particular at¬ 
tention should be given to details that guide 
possible revisions or explain reasons for 
rejection. Please summarize comments 
that appear on the manuscript in this section 
to help the author focus on the major issues 
you have raised in your review. Feel free to 
use extra sheets if necessary. 


April 1990 


15 











Information for Authors 


Scope 

Computer covers all aspects of computer 
science, technology, and applications. It is 
aimed at a broad audience. Computer pub¬ 
lishes technically substantive articles that are 
referenced extensively in the literature. Ar¬ 
ticles in Computer are often survey or tutorial 
in nature and cover the state of the art or impor¬ 
tant emerging developments. Papers describ¬ 
ing original in-depth results appealing only to a 
very narrow audience are normally not suitable 
for Computer and should be submitted to ap¬ 
propriate specialized publications. 


Writing style 

All articles should be comprehensible to 
readers outside the specialty of the article. In so 
far as possible, they should be in a style similar 
to that of Scientific American. 

Each accepted manuscript must have a suffi¬ 
cient amount of introductory material; at least 
20 percent of its total length should be of a tuto¬ 
rial nature. A brief literature survey will not be 
considered as satisfying this requirement. The 
tutorial section should include material de¬ 
scribing the principles or techniques of exist¬ 
ing approaches and their advantages and disad¬ 
vantages. 

To improve readability, the material should 
be augmented by as many tables, drawings, 
charts, or photographs as possible. Articles 
that are poorly presented due to lack of illustra¬ 
tive material will not be accepted for publica¬ 
tion. Our staff editors can polish the English in 
the text, but they cannot create illustrations or 


Manuscript length 

The length of an article should normally not 
exceed 30 one-sided, double-spaced, typewrit¬ 
ten pages of text on 8 1/2 by 11 inch paper with 
1-1/2 inch margins, although longer articles 
may be considered on their merits. Each illus¬ 
tration is counted as one-half to one full page 
of text, depending upon the complexity of the 

References 

References substantiating points made in 
the text or citing previous important and rele¬ 
vant work are listed in a separate section at the 
end of the article. Citations in the text are ac¬ 
complished by means of Arabic superscripts — 
for example. Smith'” — numbered according to 
the order of citation. 

A referenced article should be complete with 
all authors’ names, title of the article, name of 
the publication, volume and number, publica¬ 
tion date, and inclusive page numbers. For a 
referenced book, it should be complete with the 
author’s name, title of the book, publisher, 
place of publication, year of publication, and 
specific chapters or pages cited. For example. 


1. L. Watson and J. Gurd, “A Practical Data 
Flow Computer,” Computer, Vol. 15, No. 2, 
Feb. 1982, pp. 51-57. 

2. L.A. Rowe and K.P. Birman, “A Local Net¬ 
work Based on the Unix Operating System,” 
IEEE Trans. Software Engineering, Vol. 
SE-8, No. 2, Mar. 1982, pp. 137-146. 

3. J.M. Holland, K.C. Tai, and M.L. Van 
Name, “An Ada Relational Database Inter¬ 
face tJsing Abstract Data Types,” Proc. 
Compsac 81, Computer Society Press, Los 
Alamitos, Calif., 1981, pp. 163-170. 

4. D.P. Siewiorek, C.G. Bell, and A. Newell, 
Computer Structures: Principles and Ex¬ 
amples, McGraw-Hill, New York, 1982, 
Ch. 28, pp. 459-469. 

In general the references should be acces¬ 
sible to the public, such as articles in standard 
journals and open conference proceedings. 
Internal technical reports and thesis should be 
avoided, unless they are easily accessible. 

Except for unusual circumstances that 
clearly justify the use of many references, the 
number of references in an article should not 
exceed 12. 


Illustrations 

Originals for illustrations should be clear 
and easily reproducible. Line drawings should 
be in India ink on drafting cloth, paper, or 
board. Use 8 1/2 by 11 inch size sheets, if pos¬ 
sible, to simplify the handling of the manu¬ 
script. Graphs should show only the coordinate 
axes, or at most the major grid lines, to avoid a 
dense, hard-to-read result. All lettering should 
be large enough to permit legible reduction of 
the figure to column width, perhaps as much as 
4:1. If prepared in final magazine size or sub¬ 
mitted in electronic form, figure callouts are 
typeset in 8-point Helvetica Medium Con¬ 
densed, with the first word capitalized, and fig¬ 
ures are 13, 27, or 41 picas wide. Photographs 
should be black-and-white glossy prints, of 
good contrast and gradation, and preferably 
3 by 5 inches or larger. Each original must be 
numbered at the bottom of the front, all illustra¬ 
tions must be numbered, cited in the text, and 
have captions. All captions should be listed on 
a separate page. 

Author’s biographical 
sketch and photograph 

Articles should be accompanied by a good- 
quality black-and-white photo of the author 
(preferably 3 by 5 inch glossy or larger) and a 
brief biographical sketch. Information in the 
biographical sketch should be in the following 
order: current positions and technical inter¬ 
ests, prior professional experience and other 
important activities, professional affiliations, 
awards, and education. 


IEEE copyright form and 
clearances 

The author is responsible for securing all 
necessary clearances. To protect the author of a 
paper as well the IEEE, an IEEE copyright form 
must be completed for each paper before publi¬ 
cation in Computer. No paper will be accepted 
for publication until the completed copyright 
form has been received by the editor-in-chief. 

All manuscripts submitted for publication 
should be original. Papers published or under 
consideration for publication elsewhere will 
not be considered. Papers published in confer¬ 
ence proceedings of limited circulation may be 
considered for publication in Computer if they 
are of exceptional importance or contain sub¬ 
stantial new results. 


Review and editing 

Manuscripts considered for publication in 
Computer must pass a peer review process con¬ 
sistent with other standard technical periodi¬ 
cals. The author of a manuscript may request 
that it be sent to the referees with information 
on the authors (names and affiliations) with¬ 
held. The review process will normally not ex¬ 
ceed six months. 

After a paper has been refereed and the au¬ 
thor has been notified of acceptance by the edi¬ 
tor-in-chief, the manuscript will be copy-ed¬ 
ited by Computer’s staff editors. This is a col¬ 
laborative process in which the author and edi¬ 
tor work together to achieve a concise, well- 
worded article. 

Submitting a manuscript 
for publication 

To submit a paper (other than one intended 
for a special issue), eight complete copies 
should be sent to the editor-in-chief. Manu¬ 
scripts for special issues should be sent to the 
guest editors, and eight complete copies are re- 

The original illustrations, authors’ bio¬ 
graphical sketches, and photographs should 
also be sent to the editor-in-chief only after the 
manuscript is accepted for publication. 

Accepted manuscripts should be accompa¬ 
nied by floppy disk containing the article in any 
of the common word processing formats and 
operating systems. Since typesetting code dif¬ 
fers from word processing code, it is preferable 
that formatting code be removed from the disk. 

Where to submit: 

Bruce D. Shriver 

Editor-in-Chief, Computer 

Vice President for Research 

University of Southwestern Louisiana 

Drawer 42730 

Lafayette, LA 70504-2730 

Express Mail: 

Rougeou Hall, Room 225 
241 E. Lewis St. 

Lafayette, LA 70503 
Internet: shrivet@usl.edu 
Phone: (318) 231-5811 
Fax: (318) 265-5472 
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SUMMER 1990 
USEIVIX 
TECHIVICAL 
CONFERENCE 
& EXHIBITION 


Anaheim, CA 
June 11-15,1990 


TUTORIALS 

The tutorial program provides a detailed exami¬ 
nation of several UNIX topics. Two days of intensive, 
in-depth seminars will be presented by leading UNIX 
experts. Attendees needing to expand their knowledge 
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I n the days of the ENIAC and Whirl¬ 
wind, when one processor filled a 
room with vacuum tubes, few people 
could imagine lashing many computers 
together. The minicomputer enabled the 
construction of the first early parallel 
machines (C.mmp,' Cm*,' and Pluribus^). 
Only the arrival of the microprocessor al¬ 
lowed computer science to seriously con¬ 
sider machines with thousands of proces¬ 
sors. 

Since then, semiconductor technology 
has become more accessible. In 1980, 
Carver Mead and Lynn Conway published 
Introduction to VLSI Systems. They made 
this prediction: 

VLSI electronics presents a challenge, not 
only to those involved in the development of 
fabrication technology, but also to computer 
scientists and computer architects. The ways 
in which digital systems are structured, the 
procedures used to design them, the trade¬ 
offs between hardware and software, and the 
design of computational algorithms will all 
be greatly affected by the coming changes in 
integrated electronics. We believe this will be 
a major area of activity in computer science 
on through the 1980s. 

The technology of multiproject chips 
and a silicon foundry (the MOSIS system) 
operated by the US Defense Dept.’s Ad¬ 
vanced Research Projects Agency allowed 



The Monarch 
architecture team took 
advantage of custom 
VLSI in the design of a 
shared-memory parallel 
processor. The simple 
structure eases the task 
of programming a 
massively parallel 
machine. 


us to consider the design of a parallel 
processor as a complete system from sili¬ 
con to software. 

While each of the four primary catego¬ 
ries of parallel architecture — data parallel 
(Connection Machine), systolic (Carnegie 
Mellon University’s WARP), message 
passing (cubes), and shared memory 
(Sequent, Butterfly) — has its own propo¬ 
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nents, the shared-memory structure has 
been the focus of our machine designs. 

A shared-memory parallel computer is 
one in which all of the processing elements 
operate independently and are connected 
to a unified memory system. While differ¬ 
ent researchers have different definitions 
for the various categories of architecture, 
we feel that the ideal implementation of a 
shared-memory machine would have the 
following properties: 

• All of the processors would have equal 
and efficient access to all of the memory 
locations. The physical address of a mem¬ 
ory location and the delay in referencing a 
memory location would be the same from 
all processors. 

• Processors would see no additional 
delays in their memory references due to 
references made by other processors. Ide¬ 
ally, there would be no contention for 
memory and no conflicts in getting to 
memory. 

• Communications between processors 
and synchronization of the processors 
would be accomplished through the shared 
memory. 

We have constructed three machine 
families with these properties in mind. The 
first, the Pluribus,^ used the Lockheed Sue 
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Table 1. Capacities of various Monarch configurations. 


Processors 

Peak 

MIPS* 

Peak 

Mflops* 

Memory Size 
(Mbytes)** 

Memory Bandwidth 
(Mbytes/sec.) 

1 

6 

2 

2 

8 

1,024 

6,144 

2,048 

1,024 

8,192 

8,192 

49,152 

16,384 

8,192 

65,536 

65,536 

393,216 

131,072 

65,536 

524,288 


* 64-bit 

** Assuming 4-Mbit DRAMs 



minicomputer and a bus-based distributed 
crossbar switch to connect processors to a 
central memory. The largest Pluribus, 
constructed in 1974, had 14 processors. 
About 50 Pluribus machines were deliv¬ 
ered. 

The second family was BBN’s Butterfly 
parallel processor.^ Based on the Motorola 
68000 (and later the 68020), it used a 
multistage interconnection network called 
the Butterfly switch to allow the proces¬ 
sors direct access to each other’s memory. 
In 1985, we constructed a 256-processor 
Butterfly system. Over 100 Butterfly sys¬ 
tems have been delivered. 

BBN announced its TC2000 parallel 
processor in 1989. Based on the Motorola 
88000, the TC2000 can have up to 512 
processors. The Butterfly switch in the 
TC2000 has a remote memory reference 
latency of less than two microseconds and 
a bandwidth of 320 megabits per second 
per port. 

The delay to memory in these machines 
is not uniform; a processor can access its 
own local memory somewhat more effi¬ 
ciently than it can access remote memory. 
As a result, programmers normally place 
private and frequently accessed data in 
local memory, sometimes explicitly copy¬ 
ing remote data to local memory. 

In contrast, the Monarch memory sys¬ 
tem is completely uniform. Up to 65,536 
processors access a shared-memory sys¬ 
tem through a high-performance intercon¬ 
nection network. Aside from processor 
registers and an instruction cache. Mon¬ 
arch processors have no local memory. 
Every data reference is to remote memory. 
The delay in accessing remote memory is 
hidden from the programmer by matching 
the processor to the network and allowing 
the processor to execute other instructions 
while the data is being fetched. 

Supported by the DARPA Strategic 
Computing Program, we began develop¬ 
ing the Monarch parallel processor in 
1985. Today, the Monarch’s design is 
largely done and well into implementation. 
The high-speed interconnection network 
has been tested with two-micron switch 
chips, logging more than 30,000 device 
hours of operation at 125 megabits per 
second passing over 10'* bits. The proces¬ 
sor’s logic design is almost complete and 
simulated. The memory controller and 
concentrator remain to be designed. We 
have analyzed the software in detail with 
the use of hand-coded examples, a simula¬ 
tor, and a rudimentary compiler. We are 
currently seeking support to finish the 
implementation. Even so, for simplicity’s 


sake, we use the present tense when we 
refer to the Monarch in this article. 

This article contributes to the theory and 
practice of parallel processor design, pre¬ 
senting both the design of the Monarch and 
some of the reasons behind the design 
choices. The article primarily deals with 
the hardware structure of the machine. 
Another article, which will deal with key 
software issues and performance simula¬ 
tions, is currently being prepared. 

Monarch architecture 

The structure of the Monarch is simple. 
Four custom CMOS (complementary 
metal-oxide semiconductor) chips (pro¬ 
cessor, switch, concentrator, and memory 
controller) and many commercial memory 
chips implement the architecture. The 
computing power of the machine is the 
result of the mass production of moderate 
components, not an elaborate architecture. 


Table 1 shows capacities for several Mon¬ 
arch configurations. 

A single memory module contains two 
megabytes of memory and can support two 
processors. Thus, the 65,536-processor 
machine has 65,536 megabytes of physical 
memory provided by 32,768 memory 
modules. The table lists the peak perfor¬ 
mance for floating-point and integer op¬ 
erations. Based on several dozen applica¬ 
tion kernels, we expect that nearly the full 
floating point and half the integer perfor¬ 
mance can be achieved. Unfortunately, 
there are no generally accepted bench¬ 
marks for the performance of parallel 
machines, particularly for massively par¬ 
allel shared-memory machines. 

Figure 1 shows the logical structure of 
the Monarch. Thousands of processors 
access thousands of memory modules 
through a high-performance interconnec¬ 
tion network. Peripheral devices are con¬ 
nected to some processors, and a special 
system is provided for maintenance, diag- 
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(b) 


Figure 2. Synchronous operation. In 
(a), processors send references to 
memories. In (b), memories return re¬ 
sults to processors. 


nosis, and operation of the hardware. 

The Monarch operates in a simple and 
synchronous manner (see Figure 2). To 
access remote data, the processors send 
memory reference messages into the net¬ 
work simultaneously. The network routes 
the messages to the memories based on the 
destination address in the message. The 
memories then return reply messages 
through the network to the originating 
processors along the same path the mem¬ 
ory requests used. This one-microsecond 
memory referencing cycle, called & frame, 
is the basic unit of time in the machine. 
Each processor is able to perform one 
complete memory reference within each 
frame. 

The Monarch is a 64-bit machine with 
tags. Each location in memory and each 
register in the processor has 64 bits of data 
and eight bits of tag. In addition, the 
memory has full error detection and cor¬ 
rection, and the network has data and ad¬ 
dress error detection. 

Five aspects of the Monarch design 
specifically support parallel processing: 

(1) The memory system permits a pro¬ 
cessor to steal a memory location, thus 
keeping other processors from accessing 


it. This is the basic synchronization primi- 

(2) Processors use a simple address 
hashing technique to more randomly dis¬ 
tribute systematic memory references. 
This reduces the effect of memory hot 
spots. 

(3) The interconnection network 
spreads consecutive memory locations 
across the memory modules. This 
effectively interleaves the memory system 
to reduce systematic memory contention. 

(4) Read combining in the interconnec¬ 
tion network and memory controller al¬ 
lows any number of processors to read the 
same location simultaneously. Read com¬ 
bining eliminates the primary cause of 
memory hot spots — individual hot vari¬ 
ables. 

(5) A processor may reduce its load on 
the system when it is polling a variable by 
using a low-priority read. Lower priority is 
achieved by sending low-priority read 
requests only once every four frames, 
while normal traffic can be sent every 
frame. 

Monarch processors may operate inde¬ 
pendently or in concert as desired. Each 
processor may have its own instruction 
stream and its own data set, in which case 
the Monarch acts as thousands of separate 
computers. However, the processors may 
share a set of data and a single program, 
thus applying parallel processing power to 
a single problem. Even in this case, differ¬ 
ent processors will frequently be executing 
at different points in the instruction stream 
and accessing different elements of the 
data set. 

Mach, a version of the Unix operating 
system developed at CMU, allocates a 
number of these processors to each user in 
a form of space-sharing that augments the 
conventional time-sharing of processor 
resources. 

Monarch 

interconnection 

network 

The Monarch’s interconnection net¬ 
work is key to the success and viability of 
the architecture. As a framework for the 
rest of the machine, it defines a high-speed 
serial signaling strategy, a systemwide 
time frame, and rigid message formats. 
The processors and memories are designed 
specifically to match and complement the 
network. Therefore, before describing the 
rest of the machine, we will describe the 


principles behind these networks, provide 
a simple mathematical analysis of their 
performance, and address some of the in¬ 
teresting implementation details of the 
network. 

This interconnection network is a mem¬ 
ber of the family of multistage intercon¬ 
nection networks that includes the Butter¬ 
fly switch,'* the banyan, and the omega 
networks.’ Similar switches are used in the 
RPS** and the Ultracomputer.’ 

Monarch interconnection network con¬ 
figurations are highly variable. Not only 
can the number of inputs and outputs be 
varied, but the properties of contention and 
delay can be adjusted as well. Across these 
designs, the principles remain the same. 

Figure 3 illustrates a very small version 
of the Monarch network, with only 32 
input ports and 32 output ports. Each pro¬ 
cessor is represented by the letter P and 
each memory module by the letter M. 
There are two types of switching elements; 
switches and concentrators. Switches 
route messages through the network inter¬ 
connect based on an address contained in 
the first few bits of the incoming message. 
In this example, the first three bits of the 
message specify one of eight possible out¬ 
put ports. Each output port has two output 
channels, so, if either is free, the message 
moves forward along that channel. Other¬ 
wise, it is discarded and the sending pro¬ 
cessor must try again. The bits used to 
specify the output port are removed from 
the message as they are used. 

The Monarch concentrators act as statis¬ 
tical multiplexers, allocating arriving 
messages to output channels. If too many 
messages arrive, some are lost. Concentra¬ 
tors perform no routing functions for the 
network since all their outputs are con¬ 
nected to the same destination in the next 
column of the switch. The purpose of a 
concentrator is to reduce the number of 
wires presented to a later stage of the net¬ 
work by accepting many lightly loaded 
wires and producing fewer, more heavily 
loaded wires. This is particularly impor¬ 
tant at those places in the machine where 
wires are expensive, such as at the bounda¬ 
ries of system modules. 

Both the switch and concentrator use a 
pseudorandom sequence generator to se¬ 
lect which messages to allocate to output 
wires. 

A Monarch network operates stage by 
stage. Imagine that processor 0 wants to 
access a location in memory module 7. The 
processor generates a message with a rout¬ 
ing header of jl, 3,...). The first switch 
sees the first digit, the 1, and routes the 
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Figure 3. A 32-processor Monarch network. 


message to concentrator 1 using one of the 
two available channels, removing the used 
routing digit as it forwards the message. 
Concentrator 1 has an output line available 
and passes the message on to switch 1 in 
the third column. Switch 1 sees the digit 3 
and passes the message on to the desired 
memory module. The path remains open 
until the response returns along the same 
path but in the opposite direction, from 
switch 1 to concentrator 1, to switch 0, and 
finally to processor 0. 

Memory requests enter the network 
simultaneously at the beginning of the 
frame. The responses to these requests are 
returned by the end of that frame. Other 
processors use the network to access 
memory at the same time. Were they to 
present the same message to the network, 
they would access the same memory loca¬ 
tion. Memory addresses are uniform across 
the machine. 

However, when a processor sends its 
memory reference, it does not just send the 
destination memory address. Instead, it 
uses a simple technique of address hashing 
to scramble the destination memory mod¬ 
ule. Specifically, if the machine has 2" 
memory modules, the low n bits in the 
message address are replaced with the sum 
of the least significant n bits and the next 
least significant n bits of the address. This 
effectively breaks up regular data refer¬ 
ence patterns such as accesses to the rows 
or columns of an array.* 

The interconnection network is a cross 
between circuit-switching and packet¬ 
switching. Messages are routed as they 
arrive; there is no message storage in the 
network. Messages are pipelined through 
the network so that the first bits of a mes¬ 
sage leave the network before the final bits 
have even entered the network. This makes 
efficient use of the wires in the machine, 
keeps the switch nodes simple, and re¬ 
duces the delay in accessing memory. 

The Monarch switch implements read 
combining by giving special treatment to 
read requests in the interconnection net¬ 
work and at each memory module. When 
two read requests access the same memory 
location, one proceeds while the other is 
discarded but not forgotten. The switch 
remembers that both of these requests were 
to read the same memory location. When 
the reply is received from the memory, it is 
copied back to both requesters. 

For example, suppose all 65,536 proces¬ 
sors read the same location. At any point in 
the switching network without enough out¬ 
put wires to support all transactions simul¬ 
taneously, the chip will match references 


to the same memory location and deliver 
the reply to all matching requests. As a 
result of this read combining, it is possible 
for all the processors in the machine to read 
the same location in one memory cycle and 
for all to get the same result. 

Combining switches have previously 
been very expensive to build (by a factor of 
six to 32 over other switches’) because 
messages were not synchronized; they 
could arrive at the inputs of a switch at any 
time. Storage was required to hold the 
messages so that they could be examined 
and combined. The Monarch operates in a 
synchronized serial fashioh, allowing read 
requests to be combined by comparing the 
messages bit by bit as they arrive. This 
serial operation makes it possible to imple¬ 
ment a combining switch with 12 input 
ports and 16 pairs of outputs on a single IC. 

Larger Monarch networks have more 
stages of switches and concentrators and 


become much harder to draw. As an ex¬ 
ample, Figure 4 illustrates a few rows of a 
65,536-processor machine. 

The number of columns in the network is 
logarithmic in the number of inputs (n), 
and the complexity of the interconnection 
network is 0(n log^^ n). The base of the 
logarithm (b) is the number of output ports 
on the switch chips. Increasing b to the 
largest value that is still cheap to imple¬ 
ment with custom VLSI minimizes the size 
of the interconnect and the delay in access¬ 
ing memory. A switch with 12 inputs and 
16 pairs of outputs is efficient for machines 
ranging in size from 100 to 65,536 proces- 


High-speed operation. The limiting 
resource in the machine is the bandwidth 
of the interconnection network. It deter¬ 
mines the rate at which the processors can 
update the memory and the execution 
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speed of the machine. In turn, network 
bandwidth is determined largely by the 
product of the number of wires we can run 
(a mechanical issue) and the speed of an 
individual wire (an electrical issue). Data 
flows through the network serially along 
one-bit-wide channels at very high speeds. 

Knowing that the interchip signaling 
speed would determine the overall per¬ 
formance, CMOS line drivers and receiv¬ 
ers were developed that operate with lower 
than normal voltage swings and utilize 
digitally adjustable on-chip termination 
resistors that are switchable to reduce 
power consumption. Domino logic and 
other advanced IC design strategies were 
applied where needed. The result is serial 
communication at data rates of 350 mega¬ 
bits per second on each wire at a clock rate 
of 175 MHz. 

At high speeds and in large machines, 
signal and clock skew limit the signaling 


rates. This requires supercomputer manu¬ 
facturers to design with strict wire length 
constraints and sometimes to manually 
adjust the length of wires and traces on the 
circuit boards. The Monarch uses a differ¬ 
ent approach, made practical by custom 
VLSI. The chips use a patented technique 
(US Patent No. 4,700,347) to do a kind of 
electronic “wire trimming” at every input 
so that signal and clock skews are correctly 
compensated. 

Figure 5 illustrates an example of cir¬ 
cuitry for this dynamic delay adjustment. 
In this simplified example, data received 
by the input pad is sampled by one of five 
delayed versions of the clock. A clock 
selector is used to select the correct clock. 
Circuitry similar to this is present at every 
interchip data pad in the machine. 

Other circuitry uses a synchronization 
pattern sent during an otherwise idle por¬ 
tion of the frame to choose the correct 


setting for the clock selectors. By sampling 
the synchronization pattern with different 
clock phases, it can find the data transi¬ 
tions and select a clock phase that samples 
in the middle of the data bits. That circuit 
is shared by all of the pads, providing 
adjustment for one pad at a time. 

So far, we have depicted the Monarch as 
having a single network that joins N pro¬ 
cessors to N memory modules. In reality, 
the memory system is fast enough to sup¬ 
port the memory references from two pro¬ 
cessors per frame, so the processors are 
divided into two groups (called phase A 
and phase B) with their memory references 
staggered so the memory modules can 
serve each group in turn. Two separate 
interconnection networks serve each half 
of the processors. From a software view¬ 
point, this time multiplexing of the mem¬ 
ory system is invisible. From an analytic 
viewpoint, the independence of the two 
processor groups allows modeling a 
65,536-processor Monarch as two separate 
machines, each with 32,768 processors and 
32,768 memory modules. 

Interconnection network analysis. 
The mathematical model of the machine 
presented below shows that contention 
(including both interconnect and memory 
contention) reduces performance by 16 
percent for a 65,536-processor Monarch. 

The model makes several assumptions 
about the operation of the processors, in¬ 
terconnect, and memory: 

• Arbitration for resources in the net¬ 
work interconnect is random. 

• Every processor accesses a random 
location in main memory once per frame. 

• The location addressed by each pro¬ 
cessor in a particular frame is independent 
of any memory accesses made during pre¬ 
vious frames. In particular, if a memory 
request is not serviced during the current 
frame, the processor does not try the same 
address again on the next frame. 

• At each stage of the network, all of the 
wires connecting a column of switching 
elements to the next column are statisti¬ 
cally identical and independent. 

These assumptions allow a simple an¬ 
alysis of network performance, but are 
obviously suspect for real programs. The 
first assumption would be defeated by a 
program that generates a pattern of refer¬ 
ences synchronized to the pseudorandom 
sequence generators in the machine. 
However, it is very unlikely that a normal 
program would do this. 
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Figure 6. Generic switching element. 


In our simulations, we have never seen 
particularly bad effects such as tree satura- 


The second and third assumptions are 
much more troubling, because we know 
that processors do not make random ac¬ 
cesses. They sometimes access the same 
row, column, or diagonal of an array, or 
they may all access the same variable, such 
as a useful constant in the program or a 
synchronization variable. Sometimes, a 
processor makes no reference in a frame, 
reducing the load on the switch. 

The third assumption is clearly invalid. 
When a message is blocked, it is retried in 
the successive frames until it succeeds. 

Perhaps the most widely known nonran¬ 
dom network traffic occurs when many 
processors access a single memory mod¬ 
ule. This hot-spot contention has been 
studied for networks similar to the Mon¬ 
arch.’’"’ These studies have shown that 
references to memory hot spots cause 
blockage in the network known as tree 
saturation, where not only the hot spot 
references are delayed, but other unrelated 
references are delayed as well. 

In the Monarch, address hashing 
scrambles up regular data reference pat¬ 
terns to reduce hot-spot contention except 
for the case where many processors access 
the same memory location. Read combin¬ 
ing takes care of that case. 

Tree saturation begins with an uneven 
load on memory modules, but results when 
messages that fail to get through the net¬ 
work block other messages. Instead of 
holding them in the network, the Monarch 
network discards them so that they com¬ 
pete for switch resources with all other 
messages during the next frame. In this 
way, the network is fair and mostly random 
on every frame. 

The fourth assumption is also dealt with 
somewhat by address hashing (for a more 
thorough treatment, we recommend the 
detailed analysis presented in Koch.") 
Other researchers have suggested scram¬ 
bling the wires between columns in the 
interconnection network as a way of fur¬ 
ther breaking up address patterns. 

We have simulated the Monarch net¬ 
work in detail using realistic models of the 
network and application kernels running 
on the processors. In some cases, we found 
the analysis provided here to be accurate. 
In many cases, performance was a few 
percentage points better than that sug¬ 
gested by the model. An interesting effect 
occurs when processors seem to become 
synchronized in a pattern that reduces the 
contention. We have not yet done enough 
simulation to understand when this effect 
occurs. Of course, address hashing elimi¬ 
nates this form of synchronization as well. 


All of the network interconnect topolo¬ 
gies discussed here can be built from the 
generalized switch element shown in Fig¬ 
ure 6. An incoming memory reference 
arrives at one of the a inputs with 
probability P^. This equals the average 
load on an input. The incoming message 
contains an address that determines which 
of the b exit ports it will be forwarded 
through. A message can use any one of the 
c output channels of the selected exit port. 
The probability that an output channel 
carries a message is P^. 

This model applies to the switch chips 
(for example, a=4, b=%, and c=2 or 0=6, 
6=4, and c=2), the concentrator chips 
(0=16, 6=1, and c=6), and the entire main 
memory subsystem (o=32,6=32, and c=2) 
of the 32-processor example shown in 
Figure 3. 

Assuming that all of the inputs are statis¬ 
tically independent and identical, we can 
calculate the probability that an output 
channel is occupied, P^, for any switch 
configuration. First, we calculate the 
probability, P{fc), that exactly k messages 
are routed to one selected output port. Then 
we calculate the likelihood that a message 
will use a selected output channel given 


that k messages are present at the output 
port. We then sum over all possible values 
ofk. 

P{^) is given by the binomial probabil¬ 
ity mass function for the numberof arrivals 
in a Bernoulli process where the probabil¬ 
ity of an arrival is 

P^ 

J 

(the likelihood that an input has a message 
and that it is routed to a selected one of 6 
output ports). 

To get the probability that one of the 
output channels is occupied, P , we must 
sum the probability that k requests arrive at 
an output port and that a selected output 
channel will be used if k messages do 
arrive. For example, if there are two output 
ports, and one message arrives, the likeli¬ 
hood that a selected channel is used is 50 
percent. If three messages arrive, it is cer¬ 
tain that the output channel will be used. P^ 
is given as follows: 

^r=^Pill+fP|2) + ...+^^P|c-l} 

-t P{c or more} 

The probability of c or more messages 
arriving is just 1 minus the probability 
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Figure 7. P{Jt} for a 16x6 concentrator. 


that fewer than c messages arrive. 
P|cormore| = l-P101-Pil)-P(21 
Pic-11 

Therefore, 

/>^,= l-P|01-^Plll-^Pi2) 

-...-•^Picl 

Inserting Equation 1 into Equation 2 
provides the solution; that is, the probabil¬ 
ity that an output channel is active for any 
switch element configuration given that 
the inputs are statistically independent and 
identical. 

< 3 , 

For c=l and 2, the equations are simply 
P,|c=ll = l-(l-^) (4) 

P^,c=21 = l-(l-^)-f0(j-y) 

(5) 


Having derived these probabilities, we 
can relate these equations to the macro 
properties of the system. The expected 
number of input messages is a P^. The 
expected number of output messages is 
b c P ., and the efficiency of the switching 
element is 

he Pc 
a Pa 

We can now see several interesting 
properties of these switching networks. 
Consider a hypothetical implementation of 
a large Monarch that uses a full crossbar 
for its switching network by setting 
a=ft=32,768. If each memory module has 
one input port, the throughput formula for 
c=l applies (Equation 4). 

Assume that a message is presented at 
every switch input during every frame 
is 1). In that case, the efficiency is 63 
percent; put another way, 37 percent of the 
messages are lost. (Note that this ap¬ 
proaches 1/e.) This is a serious problem 
because, even with no conflicts in the inter¬ 
connection network, the conflicts at the 
memories would waste 37 percent of the 
machine. 

A solution to this problem is to provide 
many more memory modules than proces¬ 
sors — for example, consider using a fac- 
tor-of-two more memory modules. Then, 
a=32,768, 6=65,536, c=l, and the loss is 
reduced to 21 percent. This is better, al¬ 
though not much so. 

The approach we have taken for the 


Monarch is to have as many memory 
modules as processors, but to give each 
memory module two switch ports and 
design it so that it can service two requests 
at the same time. Then, from Equation 5, 
0=32,768, 6=32,768, c=2, and the effi¬ 
ciency is 90 percent (10 percent of the 
messages are lost). This is a significant 
improvement. 

In addition, if each memory module is 
able to handle two references simultane¬ 
ously, the impact of memory hot spots or 
other nonuniform traffic load will be sig¬ 
nificantly reduced. The advantage of more 
predictable behavior may, by itself, be 
worth the extra cost. 

The intuitive reason for this effect is 
that, while on average a single memory has 
only one reference, there is a significant 
probability that it will have more than one. 
This same principle applies in the switch¬ 
ing network at switches and concentrators. 
This is why we provide two channels for 
every switch port and more concentrator 
output channels than are required by the 
average load. 

Figure 7 shows PI I:), the probability 
that the concentrator in Figure 3 has k input 
messages. The average input load is four 
messages; but, by providing six output 
channels (indicated by the dotted line), we 
can reduce the loss to about three percent. 
When six or fewer messages arrive, they 
are all serviced. When more than six ar¬ 
rive, six are serviced and the remainder are 
lost. So, for k=l, only one message is lost. 
We could reduce the loss further by provid¬ 
ing more output channels. 

Multistage switching network. The 
interconnection network of the Monarch is 
a cascade of interconnected switching ele¬ 
ments of the form described above. We can 
repeatedly apply Equation 3 to each stage 
of the network to determine the network’s 
overall performance. Table 2 gives the 
efficiencies for the 32-processor configu¬ 
ration shown in Figure 3. 

The 65,536-processor Monarch has 
seven stages of interconnect, including one 
in the memory controller. Table 3 summa¬ 
rizes the configuration of each component 
and its efficiency. Overall, the system has 
16-percent contention. 

The interconnection network in the 
Monarch is carefully engineered to achieve 
low levels of contention. It is also highly 
cost-effective since, in most configura¬ 
tions, there are about as many custom ICs 
in the network as there are processors in the 
machine — the network typically adds less 
than 25 percent to the cost of the machine. 
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Table 2. Effect of contention on 32-processor design. 


a 

b 

c 

Efficiency 

Loss 




(in percentages) 

(in percentages) 

Left switch 4 

8 

2 

98.5 

1.5 

Concentrator 16 

1 

6 

97.3 

2.7 

Right switch 6 

4 

2 

93.3 

6.7 

Total 



89.4 

10.6 

Table 3. Effect of contention 

in a 

65,536-processor Monarch. 


a 

b 

c 

Efficiency 

Loss 




(in percentages) 

(in percentages) 

Switch 1 8 

16 

2 

1.0 97.7 

2.3 

Concentrator 1 32 

1 

12 

.24 99.3 

0.7 

Switch 2 12 

16 

2 

.65 97.5 

2.5 

Concentrator 2 32 

1 

12 

.24 99.5 

0.5 

Switch 3 12 

8 

3 

.63 98.6 

1.4 

Switch 4 12 

16 

2 

.62 97.7 

2.3 

Total interconnect 



90.7 

9.3 

Memory controller 8 

1 

2 

.11 93.2 

6.8 

System total 



84.5 

15.5 


The network is highly flexible; it can sup¬ 
port machines with only a few processors 
or machines with tens of thousands of 
processors. 

Monarch processor 

In uniprocessor computer design, the 
speed of access to memory largely deter¬ 
mines the performance of the machine. 
Only a modest amount of work can be done 
with data in the registers before more data 
must be drawn from memory. Fortunately, 
with one processor and one memory, it is 
often possible to locate them close together 
with short delays and wide data paths be¬ 
tween them. However, it is physically 
impossible to connect tens of thousands of 
processors directly to a large memory sys¬ 
tem; some form of communication system 
must intervene. Whatever form the com¬ 
munication system takes, it introduces 
delay in getting to memory — delay that 
can slow down the processors. 

One way to avoid this problem is to 
place a small local memory next to each 
processor, restrict the processor to access¬ 
ing only this memory, and have the proces¬ 
sors communicate in some other way. This 
is how message-passing machines operate. 

Another approach is to put a cache next 
to each processor with the presumption 
that most of the processor’s memory ac¬ 
cesses will be provided quickly by the 
cache and the impact of delay in getting to 
remote memory will be diluted. We will 
discuss caches in greater detail later. 

Both these solutions achieve their nomi¬ 
nal speed only when the software arranges 
that the desired data is in the local memory. 

In our experience, this imposes an intoler¬ 
able burden on the programmer. 

The Monarch is designed to accept the 
network delay. We run the processor at a 
speed dictated by the network. The proces¬ 
sor is crafted to make full use of the 
memory bandwidth. First, the processor 
has 64 registers so that intermediate results 
are rarely stored in memory. Second, the 
processor executes instructions in a very 
patterned way, reminiscent of wide-in- 
struction-word machines or superscalar 
architectures. This allows it to execute 
several nonmemory referencing instruc¬ 
tions during network accesses, to com¬ 
pletely overlap bookkeeping. 

As Figure 8 shows, each frame is subdi¬ 
vided into three cycles. The processor can 
start a new instruction in each cycle, and 
most instructions finish in the same cycle. 
The compiler always places memory refer¬ 


ences in cycle 0, long before the data will 
actually be needed. The data from a mem¬ 
ory read that starts in cycle 0 of frame F is 
available to an instruction that executes in 
cycle 0 of frame F-i-1; of course, cycles 1 
and 2 of frame F may be used for any 
instructions that do not depend on that 
memory data. Floating-point operations 
also require more than one cycle to com¬ 
plete, and they also overlap with other 
instructions. 

The Monarch processor has six inde¬ 
pendent functional units: two arithmetic 
logic units, a floating-point multiply and 
divide unit, a floating-point add and sub¬ 
tract unit, a memory interface unit, and an 
I/O unit. The instruction format packs two 


operations into one instruction, allowing 
the processor to perform two operations 
per cycle using two different functional 
units at the same time. This is the basis of 
the six-million-instructions-per-second 
peak instruction rate. Simulations of appli¬ 
cation kernels suggest that the ratio of six 
instructions per memory reference is rea¬ 
sonably balanced for a machine with many 
registers. 

A small local memory (three dynamic 
random-access memories) is attached to 
each processor for instruction storage. We 
think of this as a poor man’s instruction 
cache since it must be managed by the 
application or operating system software. 

The Monarch processor has a load-store 


Frame F■^ 

Frame F 

Frame F+1 T 

Cycle o| Cycle l| Cycle 2 

Cycle o| Cycle l| Cycle 2 

f 

o 

1 


Memory reference 


Figure 8. Frame timing. 
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architecture. Memory reference instruc¬ 
tions only load or store between memory 
and registers; no arithmetic or conditional 
operations deal with data in memory. This 
has allowed a straightforward extension: 
the Monarch is a load-store-srea/ architec¬ 
ture. Steal is the sole mechanism for inter¬ 
processor communication and synchroni¬ 
zation. This functions as a load instruction 
that changes a tag in the memory to mark 
the stolen word as unavailable. A proces¬ 
sor attempting to load or steal the contents 
of a stolen location receives a reply that the 
location is stolen. That processor will retry 
the load repeatedly until another processor 
stores into that location. It will then receive 
the new contents of the location. This al¬ 
lows both the efficient construction of 
higher level synchronization mechanisms 
and a primitive form of dataflow opera¬ 
tion. Programming exercises strongly 
suggest that steal facilitates efficient im¬ 
plementation of many parallel programs. 

In addition to 64 bits of data, every word 
in the machine has eight tag bits. Two are 
reserved to aid garbage collection algo¬ 
rithms; the other six provide 64 possible 
tag codes. One code is used to indicate that 
a memory location has been stolen. The 
other codes distinguish between pointers 
and other types of data and can be assigned 
by the software. These tags might be used 
to support generic arithmetic or diagnostic 
facilities. 

Memory system 

Throughout the Monarch system, we use 
cost-effective components in quantity to 
achieve high performance. In the memory 
system, we use thousands of memory 
modules to supply the memory band.width 
that thousands of processors need. These 
memory modules are independent identi¬ 
cal units consisting of one custom CMOS 
chip and two banks of memory, each with 
five four-megabit DRAMs. 

We have dual ported the memory by 
maintaining identical copies of each data 
word in two banks of DRAMs. This allows 
each controller to service two simultane¬ 
ous memory read requests — one from 
each bank. Write requests write into both 
banks so that the data is always the same in 
each. 

Each bank of memory consists of five 
DRAMs. Since each DRAM is four bits 
wide, the data path to the memory control¬ 
ler is 20 bits wide. When a memory refer¬ 
ence occurs, four page-mode operations 
are used to transfer 80 bits: 64 bits of data. 


eight bits of tag, and eight bits of error 
detection and correction. 

The memory controller performs three 
memory functions — read, write, and steal 
— based on requests from the switch. The 
memory controller also provides error 
detection and correction on the DRAM 
contents. Memory refresh is synchronized 
across the machine so that its impact is 
limited. 

The memory controller does read com¬ 
bining with its eight inputs, so accesses to 
the same location are combined and only 
one read is performed. In addition, the 
memory controller has a small queue of 
write requests, allowing the memory con¬ 
troller to service, say, two read requests 
and four write requests during the same 
frame. Write requests are serviced when 
time allows. Rough analysis indicates that 
this should reduce memory contention by 
another factor of two, assuming one-third 
of the data references are writes. 

I/O system 

“While designing the IBM System/360, Gene 
Amdahl postulated two rules of thumb for a 
balanced system. The first rule related [pro¬ 
cessor] size with [main memory] size, stating 
that one byte of [memory] was required to 
support each instruction per second. The 
second rule related [processor] speed with 1/ 
O bandwidth, stating that one bit of I/O was 
required to support each instruction per sec¬ 
ond”.'^ 

On average, a 65,536-processor Mon¬ 
arch executes about 200 billion instruc¬ 
tions per second. It has a trillion-byte vir¬ 
tual address space and a 137-billion-byte 
physical address space. Initially, the ma¬ 
chine will have 65 gigabytes of main 
memory, but 16-megabit DRAMs fill the 
physical address space. In memory size, 
the Monarch is well balanced. 

On the I/O side, Amdahl’s rule of thumb 
suggests 25,000 megabytes per second of 
I/O capacity. It is hard to imagine what to 
connect to the Monarch at such a high rate. 
Very-high-performance video displays 
(1,500x1,000,48-bit color, 75-Hz refresh) 
would refresh at 675 megabytes per sec¬ 
ond, and 37 of these would absorb this 
bandwidth. So would a disk system with 
2,000 very-high-speed disks (14-mega- 
byte transfer rate). 

Just as the central processing portion of 
the Monarch achieves high performance 
through the use of many moderate-per¬ 
formance processors operating in parallel, 
the Monarch I/O system also achieves high 
performance by using a large number of 


moderate-speed, cost-effective I/O de¬ 
vices operating together. This matches the 
performance of an I/O device to our pro¬ 
cessor and provides an o^ortunity to 
achieve exceptional reliability in the I/O 
system. 

A 65,536-processor Monarch has up to 
2,048 additional I/O processors. These I/O 
processors are identical to the other pro¬ 
cessors in the machine, and are connected 
to extra ports on the switch, but have a 
high-speed (four wire) link connecting 
them to the I/O devices. We estimate that 
each I/O processor can support a sustained 
bandwidth of about two megabytes per 
second. A machine with 2,048 I/O proces¬ 
sors would have a total I/O bandwidth of 
4,000 megabytes per second, short of 
Amdahl’s rule by less than an order of 
magnitude. In the compute-bound applica¬ 
tions for which the Monarch is intended, 
this I/O bandwidth will probably be 
adequate. 

The disk system of the full-size Mon¬ 
arch will consist of about 200 small Win¬ 
chester disks operating together. To maxi¬ 
mize the peak transfer rate into and out of 
the machine, we dedicate one I/O proces¬ 
sor to each drive. The system software of 
the machine performs reads and writes to 
the disk system in blocks. By spreading the 
data from a block over eight separate disk 
drives, we can increase the peak transfer 
rate to 16 megabytes per second for a 
single transfer and more than 400 mega¬ 
bytes per second for the whole system. 

Parallelism also provides an opportu¬ 
nity to improve the system’s tolerance of 
errors. Adding a ninth disk to each group of 
eight will ensure that the failure of any disk 
drive, any disk controller, any I/O proces¬ 
sor, or any disk I/O system cabinet will not 
disable the machine. In fact, the machine 
will continue to run without interruption. 
This is achieved by placing eight sectors 
on the eight data disks and the bit-by-bit 
exclusive OR of these sectors on the ninth 
disk. When these eight sectors are read, the 
system can detect if one is missing or in 
error. The missing sector may be recov¬ 
ered by taking the exclusive OR of the data 
from the seven other sectors and the ninth 
sector. Commercial multiple disk systems 
of this form are now becoming available. 

Maintenance and 
diagnostic system 

Control of the Monarch hardware is 
accomplished by a maintenance and diag¬ 
nostic system to which every custom chip 
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Figure 9. Floor plan for a 65,536-processor Monarch. 


in the machine is attached. This MDS al¬ 
lows a separate maintenance computer to 
control and monitor the machine independ¬ 
ently of the operational software. 

The custom devices are designed so they 
can be adapted to a particular machine 
configuration. Values such as the length of 
the frame, the expected arrival time of 
messages, and many others can be set 
according to the machine size and the loca¬ 
tion of the chip in the machine. The MDS 
can also access the memory in the machine 
to load bootstrap programs. Even the syn¬ 
chronization of frame time and the estab¬ 
lishment of data recovery across the ma¬ 
chine are controlled by the MDS. 

During normal system operation, error 
detection circuitry monitors every mes¬ 
sage flowing through the interconnection 
network, e,very instruction memory and 
global memory reference, and clock and 
signal timing throughout the machine. In 
case of a fault, the chip takes whatever 
action is appropriate at the time and sets a 
status bit that the MDS can read as it 
periodically scans the chips. In the case of 
correctable errors, such as soft memory 
errors, the MDS may accumulate statistics 
or excise the defective component for more 
thorough off-line diagnosis. 

The MDS is responsible for diagnosing 
faults in the machine. Special facilities are 
built into the custom devices to allow this. 
For example, every custom chip can con¬ 
trol and monitor its input and output pins. 
Since all of the signaling wires in the 
machine terminate in our custom chips, 
this facility allows the MDS to perform a 
full continuity check on the data paths of 
the machine. 

Packaging 

Monarch machines can vary in size front 
1,024 to 65,536 processors and from 1,024 
megabytes to 65 gigabytes of memory. All 
of these machines can be built using the 
same key components; 

• A processor board with 128 processors 
and a 16-way switch. 

• A memory board with 128 memory 
controllers and a 384-input switch. 

• A switch board with 192 input ports 
and 16 output ports with 12 channels 
each. 

• Utility boards for clock and MDS dis¬ 
tribution. 

Because of the dynamic delay adjust¬ 
ment technique, a Monarch machine can 


be physically small or large without too 
much concern for signal or clock skew. 
The size of the machine is limited by the 
losses in the cables that interconnect cabi- 

At the low end, we can imagine a ma¬ 
chine with eight processor boards, four 
memory boards, one utility board, and no 
switch boards. This machine would have 
1,024 processors and 262 megabytes of 
memory. It would fit in a single card cage 
about 18 inches wide, 24 inches high, and 
36 inches deep. It would dissipate about 10 
kilowatts and could be cooled by forced 

The largest machine uses the same 
boards, but requires special cabinetry. An 
initial design for a 65,536-processor ma¬ 
chine fills much of a 40-by-40-foot room, 
as Figure 9 shows. 

The central machine occupies 16 cabi¬ 
nets arranged in a circle. Inside the circle is 
a wiring mat that interconnects the cabi¬ 
nets. The other cabinets arranged around 
the room contain disk drives, AC power 
and cooling control and distribution cabi¬ 
nets, and the MDS maintenance comput¬ 
ers. This design is quite dense and requires 
water-cooled intercoolers within the cabi¬ 
nets to remove the heat generated by the 
computer. As the design continues to 
evolve, we expect to achieve improve¬ 
ments in the packaging. 


Redundancy and 
reliability 

One of the primary advantages of a 
multiprocessor architecture is that with so 
many processors and memory modules, it 
would seem possible to survive the loss of 
some of the components without much 
effect on the overall machine. In case of a 
failure, it might be possible to provide 
uninterrupted service in some instances. In 
others, it would be necessary to stop the 
machine, reconfigure, and restart the op¬ 
eration. In any case, we would expect the 
machine to be highly available with little 
downtime. 

The most prominent failure modes are 
the ones that occur at the module level: 
processors, switch, concentrator chips, 
memory modules, and interconnect. In 
each case, the system design provides 
redundancy so that many single-point fail¬ 
ures can be tolerated. For example, at the 
boundary between each processor and 
memory board, 12 identical wires are 
available. If one or two of them are defec¬ 
tive, it is still possible to access memory; 
the only effect is a slight increase in the 
conflict rate. It is easy to imagine that the 
machine would survive a failure of even 
hundreds of these paths. Similarly, it is 
possible that a connection between a 
switch chip and a concentrator chip will 
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fail. Since every switch chip output port 
has two redundant paths to the same desti¬ 
nation, a single-point failure can be toler¬ 
ated on any switch-chip-to-concentrator- 
chip path. 

There are several options for dealing 
with the failure of a memory module. The 
one that we currently favor is to supply a 
spare module and put a small mapping 
table in each switch chip. The mapping 
hardware can be designed to permit rerout¬ 
ing of memory requests to spare modules 
in the course of the normal routing process. 

Processor failure is perhaps the easiest 
to deal with in principle because it is sim¬ 
ply a matter of excluding faulty processors 
from the pool of active processors. 

Design alternatives 

During the Monarch design, many alter¬ 
natives were considered and discarded. In 
this section, we review a few of the most 
interesting, or perhaps most popular, alter¬ 
natives. 

Commercial processors. While it 
might appear that we should purchase a 
commercial processor and interface it to 
the network (as we did with the Butterfly 
machine), the impediments to this ap¬ 
proach are significant. High-end commer¬ 
cial microprocessors are designed for a 
physically small system where the proces¬ 
sor is the heart of the system. Memory is 
close to the processor, so the latency to 
memory is a fraction of a microsecond. 
Wires are cheap, so data paths are at least 
32 bits wide. 

In the Monarch, the memory is farther 
away, so latency is almost a microsecond; 
wires are expensive, so it is worthwhile to 
run a few wires at high speed; and the 
processor is duplicated many times. Paral¬ 
lel processing requires sophisticated inter¬ 
processor synchronization (in our case, the 
steal instruction). A test-and-set instruc¬ 
tion or compare-and-swap is not good 
enough. Finally, a highly parallel shared- 
memory machine will be called on to solve 
large problems and requires a very large 
memory system (32-bit addresses are too 
small). As the Monarch design has pro¬ 
gressed, it has become clear that a machine 
with these qualities could not be designed 
today based on commercial microproces- 

Caches. Caches have been used for 
years in mainframe computer designs to 
match a fast processor to a slower bulk 


memory. Many shared-memory machines 
now use caches to reduce the load on the 
interconnection network. The Monarch 
has an instruction cache for just that pur¬ 
pose. However, we rejected the use of a 
data cache next to every processor because 
of the low hit rate of data caches, the 
difficulty in maintaining cache consis¬ 
tency, and the incompatibility of caches 
with the Monarch programming methodol¬ 
ogy. 

Even in uniprocessor systems, data 
caches rarely achieve hit rates of 90 per¬ 
cent, because of the read-once nature of 
data in large databases, sparse matrices, 
hash tables, sequential records, heaps, etc. 
Since a cache miss often results in an order 
of magnitude longer access time than a 
cache hit, a data cache with a hit rate of less 
than 90 percent throws away half the per¬ 
formance of the machine while imposing a 
significant cost. 

In addition, maintaining consistency of 
these caches in a large parallel processor is 
a complex and challenging problem. In a 
bus-based parallel processor, snooping 
may be used to assure cache consistency. 
However, above about a dozen processors, 
the traffic on the bus needed to support 
snooping becomes a problem and more 
elaborate cache consistency algorithms are 
needed. In a system with 65,000 proces¬ 
sors, cache consistency is an unsolved 
problem. 

In the Monarch programming style, 
processors are considered equal, inter¬ 
changeable resources. A processor be¬ 
comes available, mutates data in memory, 
and moves on to the next task. There is 
little time for a processor to fill its cache 
with its working set and little reason to 
expect that the same processor will deal 
with the same data during the next phase of 
operation. 

Furthermore, in a parallel processing 
system, shared data might migrate from 
cache to cache — rarely being in the right 
place at the right time. Since caches add to 
system cost and complexity and frequently 
provide poorer access times in the case of 
a cache miss, it is very important that the 
cache hit rate be high just to break even. It 
is impossible to be confident that this cache 
hit rate will be acceptably high for arbi¬ 
trary programs and data sets that have not 
yet been developed. Accordingly, we have 
taken the safe and conservative position of 
not using data caches. 

Faster processors. Faster processors 
than the ones proposed for the Monarch are 
now available. We could use one of these 


faster processors and reduce the size of the 
machine. For example, instead of 65,000 
six-MlPS processors, we could opt for 
6,500 processors, each 10 times faster (60 
MIPS). Would such a machine be one- 
tenth the size, one-tenth the cost, and 10 
times easier to program? 

The Monarch processor is a single cus¬ 
tom chip with three DRAMS; 128 proces¬ 
sors fit on a large processor board. Will 
128 fast processors with caches and a fast 
switch interface fit on the same board? The 
Monarch processor currently costs less 
than $100; 60-MIPS processors are much 
more expensive than that, even without the 
switch interface. 

Simply scaling the machine with a pro¬ 
cessor that is 10 times faster would require 
the interconnection network to be 10 times 
faster as well, with access to 6,500 mem¬ 
ory ports in 100 nanoseconds. Ten ports of 
the Monarch switch could be used in paral¬ 
lel to achieve 10 times the bandwidth, but 
that would not reduce the delay. We can 
imagine increasing the bit rate by a factor 
of 10 (to 3.2 gigabits per second) through 
gallium arsenide. This would reduce the 
latency across the switch to some extent, 
but, with 20-foot cables in the network, 
speed-of-light delays to and from the 
memory are about 50 nanoseconds, leav¬ 
ing 50 nanoseconds for switching and 
memory access. 

It would be nice to decrease the size of 
the machine and reduce the cable length, 
but if exotic techniques such as liquid 
cooling or wafer scale integration are 
needed, they could be applied to the Mon¬ 
arch as well. 

The resulting machine with 6,500 pro¬ 
cessors is still a highly parallel machine 
with difficult programming considera¬ 
tions. The step from one processor to many 
is difficult to deal with, but we do not 
believe the step from 6,500 to 65,000 is 
very significant. 

In our opinion, the true issue in the 
trade-off between the speed of the proces¬ 
sors and the number of processors is not 
one of cost/performance, but one of algo¬ 
rithm structure. In a design with fast pro¬ 
cessors and data caches, the programmer 
must ensure the locality of data accesses. 
In a design without data caches, the pro¬ 
grammer must find and exploit a greater 
degree of algorithm parallelism. In either 
case, to achieve massive performance, 
massive parallelism will be required. We 
feel that it is much easier to deal with many 
processors when there are no restrictions 
imposed by a nonuniform memory struc¬ 
ture. 
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“After more than a year of 
fits and starts, my simulations 



tvere running in parallel the first day 

with Express! ... • Pm a theorist who needs serious 60 bit floating point 

throughput in classical and quantum simulations of liquids, and in studies of 
quantum chaos, but who enjoys the flexibility of the MAC environment Adding 
transputer boards to a MACH seemed like the perfect match, with the possibility of 
almost limitless scaling up, once the system proved itself However, initial progress 
was dismal! The parallel languages supplied were enormously cumbersome, raising 
issues of connectivity and inter-node communication I didn’t want to face. 
Further, and even more problematic for me, understanding the MAC-transputer 
interface required systems-level programming at a level of pain well above the 
threshold of a result oriented physical scientist. I was literally planning to chuck the 
transputer network, as an interesting but failed experiment A chance call from a 
friend, who had made a similar assessment, sent me to ParaSoft Within hours 

parallel codes written in ordinary C, with a few 
calls to Express subroutines, were running 
with near perfect speed-up as new 
. tran^uters were added to the 
system. My basic classical and 
quantum dynamical subroutines 
run in parallel without modifica¬ 
tion. I/O and connectivity are 
completely transparent, even color 
contouring is easily done in par¬ 
allel Systems level and MPW con¬ 
cerns are a thing of the remote past 
I now have 10% of a GlAY I on my 
desk, and am happy as a clam. ” 


Professor William Reinhardt 


University of Pennsyivania Chemistry Department and Materials Research Laboratory 


Dr. Reinhart’s experience is typicai of many users 
of the ParaSoft software system. Instead of strug¬ 
gling with inadequate tools and system level pro¬ 
gramming Issues Express brings to the user a 
library of high-level parallel processing routines 
and automatic decomposition utilities. Coupled to 
this is an I/O and graphics system, a source level 
debugger and a set of performance analysis tools 
that ALL WORK IN PARALLEL. To users of Express 
parallel programming is just like sequential 
programming. 

Another advantage of Express Is its availability 
on a range of parallel computing systems. Currently 
supported are many different transputer systems 
and parallel computers from NCUBE, Symult and 
Intel with new machines being added all the time. 


ParaSoft 


Users of Unix. MS-DOS and Mac 0/S can all take 
advantage of Express - without having to learn a 
new operating system. On each type of machine 
the same Express programs will work - you choose 
your architecture to match your performance 
requirements. Furthermore Express programs 
scale with the addition of more processors to a 
given machine allowing growth limited only by your 
pocketbook. 

Express has been used in both educational and 
commercial environments with great success. In 
the latter category recently available applications 
include the NeuralWorks II neural network 
simulator from NeuralWare and the COSMOS/M 
finite element system from Structural Research. 
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W e believe that the shared- 
memory computer architec¬ 
ture is the most flexible archi¬ 
tecture currently under study. With it, 
many differing programming styles can be 
used efficiently. While it is difficult to 
assess the performance of a machine until 
it has executed many benchmarks and 
many real application programs, we have 
coded more than two dozen benchmark 
programs in an attempt to determine the 
performance of the Monarch. The results 
of this study confirm that large programs 
contain enough parallelism to use 65,536 
processors and that the architecture of the 
Monarch permits efficient use of the ma¬ 
chine’s resources. ■ 
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Matrix Computations 
on Systolic-Type 
Meshes 

An Introduction to the 
Multimesh Graph Method 


Jaime H. Moreno and Tomas Lang 
University of California, Los Angeles 


M atrix computations, character¬ 
ized by having matrix operands 
and/or results, are a frequently 
used mathematical tool in modem scien¬ 
tific and engineering applications. For 
example, in a review of parallel-pro- 
cessing algorithms and architectures for 
real-time signal processing, Speiser and 
Whitehouse' indicated that the major com¬ 
putational requirements for many impor¬ 
tant real-time signal-processing tasks 
(such as adaptive filtering, data compres¬ 
sion, beam-forming, and cross-ambiguity 
calculation) can be reduced to a common 
set of basic matrix computations. This set 
includes matrix-vector multiplication, 
matrix-matrix multiplication and addition, 
matrix inversion, solution of linear sys¬ 
tems, eigensystems solution, matrix de¬ 
compositions (LU-decomposition, QR- 
decomposition, and singular-value decom¬ 
position [SVD]), and the generalized SVD 
algorithm. 

Matrix operations of the type mentioned 
above are computation intensive. Conse¬ 
quently, they require high computing rates 
to achieve acceptable execution speed and 
to meet the time constraints of many appli¬ 
cations. Thus, parallel algorithms and 


Systolic-type arrays use 
both the fine-grain 
parallelism and the 
regularity of matrix 
computations effectively. 

The multimesh graph 
method for deriving 
these arrays is 
systematic, flexible, and 
easy to use. 


architectures are often needed.^ As Figure 
1 shows, several classes of parallel archi¬ 
tectures have been used for matrix compu¬ 
tations. Vector computers, for example, 
exploit parallelism through vector instruc¬ 


tions, extracted from sequential programs 
by vectorizing compilers. Array comput¬ 
ers use a similar type of parallelism. Multi¬ 
processor systems, on the other hand, 
exploit parallelism at several levels, in¬ 
cluding vector operations, concurrent exe¬ 
cution of several loop iterations, and block 
methods. Because of their importance, 
matrix computations have become one of 
the preferred benchmarks for parallel 
architectures.^ 

Although the above-mentioned parallel 
architectures have demonstrated their ef¬ 
fectiveness for executing matrix computa¬ 
tions, they suffer from several degradation 
factors. These arise from the relative gen¬ 
eral-purpose character of the machines and 
from the need to adapt the algorithms to the 
specific hardware. Moreover, their gen¬ 
eral-purpose nature makes it necessary to 
include features that increase cost (for 
example, complex memory-addressing 
schemes) and also make the architectures 
less suitable for very large scale integra¬ 
tion (VLSI) and wafer-scale integration 
(WSI) technology (broadcasting or com¬ 
plex interconnection networks, for ex¬ 
ample). These drawbacks led to the intro¬ 
duction of application-specific architec- 
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tures and, in particular, of systolic-type 
arrays, which are natural for matrix com¬ 
putations because they match the fine 
granularity of parallelism available in the 
computations and have very low overhead 
in communication and synchronization. 
(This contrasts with dataflow computers, 
which also use fine-grain parallelism but 
have high overhead.) In addition, the regu¬ 
lar nature and nearest-neighbor connec¬ 
tions of systolic-type arrays meet the re¬ 
quirements for effective use of VLSI and 
WSI." 

This article focuses on the execution of 
matrix computations on systolic-type ar¬ 
rays in an application-specific environ¬ 
ment. We first present an extension to the 
concept of a systolic cell by incorporating 
a small, fixed amount of storage inside the 
cells, and we discuss the trade-offs this 
storage gives rise to. Then we review dif¬ 
ferent approaches to decomposing (parti¬ 
tioning) large problems, highlighting their 
bandwidth requirements and their capa¬ 
bilities for using the storage in the cells. 
Finally, we discuss the basic characteris¬ 
tics of methods for the design of systolic- 
type arrays, describe the multimesh graph 
(MMG) design method, and illustrate its 
application to the transitive closure algo¬ 
rithm. Other examples, including LU-de- 
composition, QR-decomposition, and the 
Faddeev algorithm, are given elsewhere.® 

Although applying the MMG method to 
the examples indicated above has pro¬ 
duced arrays whose cells are simpler and 
better utilized than those in previously 
proposed structures for the same algo¬ 
rithms, this article concentrates on the 
method’s capabilities rather than on the 
arrays obtained. 


Algorithms and 
systolic-type arrays 

Several algorithms may exist for a given 
computation. Some of these algorithms 
are suited for sequential execution (that is, 
in a single processor), while others are 
better suited for particular types of parallel 
architectures. Matrix computations have 
properties that make them attractive for all 
the architectures mentioned earlier, and 
many algorithms have been developed for 
the different classes. For execution in 
systolic-type arrays, the algorithm should 
exhibit sufficient fine-grain parallelism. 
This is often characteristic of traditional 
algorithms used in sequential computers, 
but in other cases special algorithms have 
been developed.® 



Depending on their range of applicabil¬ 
ity, there are two types of application- 
specific arrays: algorithm specific and 
class' specific. Algorithm-specific arrays 
can execute only one particular algorithm. 
As Figure 2a illustrates, these structures 
may be the most appropriate solution for 
some applications because they offer the 
possibility of matching an array to a given 
algorithm and of fulfilling specific im¬ 
plementation requirements (such as speed, 
size, and power consumption). If the appli¬ 
cation consists of the matrix operation and 
other computations, the array should be 
combined with other modules to perform 
the complete task, composing a heteroge¬ 
neous system. In addition, such an array is 
usually connected to a host that performs 
I/O and control functions. The realization 
of an algorithm-specific array consists of 
determining 


• the topology of the array (triangular, 
linear, rectangular, etc.), 

• the functionality of each processing 
element, 

• the schedule of operations and data 
transfers, and 

• the I/O schedule. 

By contrast, in some situations the set of 
matrix computations is varied and not even 
predefined. In these cases a better solution 
is a class-specific array, that is, a general 
array that can be adapted (programmed) 
for a class of matrix algorithms, as Figure 
2b illustrates. Programming a class-spe¬ 
cific array consists of determining 

• the assignment of operations to cells, 

• the schedule of operations and data 
transfers, and 

• the I/O schedule. 



Figure 2. Classes of application-specific arrays for matrix computations: (a) al¬ 
gorithm specific, (b) class specific. 
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Glossary 

Matrix computation — A computation having matrix operands and/or results. 

Fine-grain paraiieiism — Parallelism at the level of basic (arithmetic) operations. 

Array processor — A network of processing elements (PEs) that execute the same operation, synchronously, on different 
data elements: the operation is broadcast to all PEs. 

Array (processor array) — A hardware network of processing elements with nearest-neighbor communication (no broad¬ 
casting). 


Cell — A processing element. 

Systolic-type array — A two-dimensional processor array with cells of similar complexity connected in regular nearest- 
neighbor manner, synchronized dataflow, and external I/O only at boundary cells. 

Mesh array — A systolic-type array with cells connected by unidirectional orthogonal nearest-neighbor links. 

Systolic cell — A cell with no local storage. 

Pseudosystolic cell — A cell with a small, fixed amount of local storage. 

Local-access cell — A cell with storage proportional to the size of problems. 

Pipelined cell — A cell capable of performing several operations simultaneously by pipelining execution of operations 
through several computing stages within the cell. 

Stage time — The time taken by a stage of a pipelined cell. 

Optimal utilization of cells — A new operation is initiated in every computing cycle. 


Application-specific array — An array designed for specific purposes (in contrast with general-purpose architectures, 
which are designed for [almost] any purpose). 

Algorithm-specific array — An array designed for one algorithm. 

Class-specific array — An array suitable for a class of selected algorithms. 


Realization of an array — The design of an application-specific array for a given algorithm or class of algorithms (topol¬ 
ogy, functionality of cells, scheduling, data transfers, data I/O). 

Mapping onto an array — Determining the execution of an algorithm on a predefined array (operations per cell, schedul¬ 
ing, data transfers, data I/O). 


Partitioning — Decomposing a large problem for execution on a small array. 


Both algorithm-specific and class-spe¬ 
cific cases should meet the requirements of 
a particular application and should opti¬ 
mize relevant criteria. Consequently, the 
design of an algorithm-specific array and 
the programming of a class-specific struc¬ 
ture have many aspects in common, and 
similar techniques can be used for both 
activities. We refer to these tasks as reali¬ 
zation and mapping, respectively. In this 
article we concentrate on the realization of 
application-specific arrays for matrix al¬ 
gorithms. Mapping is discussed exten¬ 
sively elsewhere.’ 

Systolic and 
pseudosystolic 
mesh arrays 

Let’s examine the properties of an archi¬ 
tectural model consisting of a mesh of 


processing elements (cells) with unidirec¬ 
tional orthogonal links. We refer to this 
architecture as a mesh array (see examples 
in Figure 3). These arrays are hardware 
networks of processing elements with the 
following basic characteristics: 

• linear or two-dimensional structures 
with cells connected in nearest-neigh¬ 
bor manner (a linear array with K cells 
is a mesh of dimension AT by 1); 

• external I/O from a host only at the 
boundaries of the array; 

• unidirectional communications be¬ 
tween cells, that is, dataflow from cell 
to cell in one direction only, without 
data counterflow; and 

• local communications only, that is, no 
capability for broadcasting or routing 
data through cells without using that 
data. 

Analysis of a large class of matrix algo¬ 


rithms has shown them to consist of primi¬ 
tive operations with up to three operands 
and up to two results, as Figure 4a illus¬ 
trates. Since cells of linear and two-dimen¬ 
sional mesh arrays have only two input and 
two output ports, the third operand is ob¬ 
tained from a feedback loop within the cell 
(Figure 4b). So, for ternary operations 
(those requiring three operands), two 
sources of data are off-cell and the third 
source is a feedback loop within the cell. 
On the other hand, the outputs from a cell 
can be either results computed within the 
cell or operands used in the cell and passed 
through without modification (that is, 
transmitted data^). 

We assume that the execution time is the 
same for all operations and that the stage 
time is the same in pipelined cells. These 
assumptions, customarily used for the de¬ 
sign of application-specific arrays, are 
highly implementation dependent. 

In terms of the communication band- 
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Figure 3. Examples of mesh arrays. 



Figure 4. Primitive operation (a) and cell (b). 


width, we consider three types of cells: 

(1) Systolic cell — a cell with no local 
storage except for registers used to latch 
input operands (Figure 5a). Data flows 
through cells, so every operation in each 
cell requires one data transfer per data 
source. Consequently, the communication 
rate is the same as the computation rate of 
cells. 

This type of cell is suitable for imple¬ 
mentation in wafer-scale-integration tech¬ 
nology because an entire array can be 
placed on a single wafer and there is no 
need to go off-wafer for communicating 


between cells. This is in contrast to very 
large scale integration technology, where 
only a few cells are placed on a chip, so that 
it is necessary to go off-chip to communi¬ 
cate between cells. The off-chip transfers 
degrade speed because of the lower band¬ 
width. 

(2) Pseudosystolic cell — a cell with a 
small, fixed amount of storage (the amount 
of storage is independent of the size of 
problems to be solved in the array). This 
storage comprises two separate FIFO buff¬ 
ers, one for the vertical flow and the other 
for the horizontal flow of data through the 
array. Figure 5h depicts a pseudosystolic 


cell with its ports and buffers. The ports 
and/or local storage provide two sources of 
data for every operation; the third source is 
a feedback loop within the cell. 

Since the size of the FIFO buffers is 
fixed and small, we assume that access 
time to this local storage matches the exe¬ 
cution rate of the functional unit (that is, 
cell pipeline stage time or functional unit 
time) and that it is shorter than the time 
needed to transfer data between cells. This 
property is exploited by performing suc¬ 
cessive operations with data from the buff¬ 
ers, without accessing the ports. Conse¬ 
quently, pseudosystolic cells need not 
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Figure 5. Different types of cells: (a) a 
systolic cell, (b) a pseudosystolic cell, 
(c) a local-access cell. 


receive data through the ports at every 
cycle, so the communication bandwidth of 
pseudosystolic cells is lower than their 
computation rate. This lower communica¬ 
tion rate is adjusted to the cell computation 
rate by FIFO queues attached to the ports. 


Pseudosystolic cells are suitable for 
implementation as one cell per chip be¬ 
cause they have only a small amount of 
local memory and the off-chip communi¬ 
cation rate is lower than the on-chip com¬ 
putation rate. The amount of storage deter¬ 
mines the relation between these rates, as 
weTl see later. 

(3) Local-access cell —a cell with stor¬ 
age space proportional to the size of prob¬ 
lems to be solved in the array (Figure 5c). 
Operations are performed in each cell with 
up to two operands obtained from local 
storage, so that data received from neigh¬ 
bor cells is stored before it is used. Another 
source of data is the feedback loop within 
the cell. 

Local-access cells have sufficient 
memory to store a large portion of the data 
locally and to reduce communications 
between cells. Consequently, the commu¬ 
nication rate is much lower than the com¬ 
putation rate (much less than one word per 
port per time-step). Local-access cells are 
suitable for implementation at the board 
level because they require a large local 
memory. 

The remainder of this article will focus 
on systolic and pseudosystolic cells. A 
discussion on the use of local-access cells 
in arrays for matrix computations appears 
elsewhere.^ 

The model of computation used in mesh 
arrays consists of the synchronized flow of 
data through cells (Figure 6a), with opera¬ 
tions performed in each cell. At each time- 
step, a cell reads operands from input ports, 
local storage, and/or the feedback loop; 
performs an operation; and delivers results 
to output ports, local storage, and/or the 
feedback loop. For pipelined cells the 
model of computation is similar, except 
that the results delivered to ports, the feed¬ 
back loop, and local storage are from an 
operation previously initiated in the pipe¬ 
line. 


Size of problem 
and array 

The relative size of the matrices and of 
the array significantly affects the design 
and operation of the computing structure. 
Two different cases can be identified. 
When the matrix size is fixed, the array can 
be designed to use the maximum parallel¬ 
ism achievable. When the matrix is much 
larger (its size may not even be predefined) 
than a cost-effective array, the computa¬ 


tion is partitioned into subproblems, which 
are executed in sequence on the array (par¬ 
titioned problems*). Consequently, the 
array is used many times while operating 
to solve a single large problem. 

The model of computation described 
earlier is suitable for fixed-size algorithms 
executed repeatedly with different sets of 
input data (multiple-instance algorithms) 
or for partitioned algorithms. In either case 
an instance (or subproblem) can use a cell 
during several time-steps, and various 
instances (or subproblems) can execute 
concurrently throughout the array. Figure 
6b depicts the flow of several instances 
through a mesh array. 

There are different approaches to parti¬ 
tioning a problem, depending on the type 
of cells used. The approach suitable for 
systolic and pseudosystolic cells is a two- 
level scheme wherein the algorithm is 
decomposed into subproblems and each 
subproblem is decomposed into compo¬ 
nents. A subproblem is mapped onto the 
entire array, and each component is 
mapped onto a different cell. Subproblems 
are executed in pipelined fashion, accord¬ 
ing to a certain schedule. This sequential 
execution requires feedback of data and 
memory external to the array, but little or 
no storage inside the cells (depending on 
the components of the subproblems, to be 
described later). This approach produces 
good load balancing. 

As an example. Figure 7 illustrates an 
algorithm partitioned into subproblems 
whose components exhibit a rectangular 
communication pattern (except at the 
boundaries of the algorithm). Conse¬ 
quently, subproblems are executed in a 
rectangular array. This type of partitioning 
is known as cut-and-pile} It has also been 
referred to as locally parallel globally 
sequential partitioningj 

On the other hand, the approach suitable 
for local-access cells partitions the entire 
algorithm into a number of subproblems 
equal to the number of cells in the target 
array, and it maps each subproblem onto 
one cell. As a result, the dependencies 
among the subproblems should match the 
interconnection structure of the array, cells 
must have a large amount of local storage 
(enough to store all data for the corre¬ 
sponding subproblem), and cells need low 
bandwidth. However, this scheme requires 
a careful selection of subproblems to 
achieve good load balancing. 

Figure 8 shows this technique, wherein 
an algorithm is partitioned into a number 
of communicating subproblems that are 
mapped onto the array. This type of parti- 
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Figure 6. Computational model of mesh arrays: (a) flow of data per cell, (b) flow of data in an array. 



Figure 7. Partitioning through cut-and-pile. 
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Figure 9. Partitioning through decomposition into suhalgorithms. 
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Figure 10. The stages in a design method. 


tioning is known as coalescing} It has also 
been referred to as locally sequential glob¬ 
ally parallel partitioning.'' 

A different partitioning strategy, shown 
in Figure 9, was proposed by Navarro et al.* 
In this case an algorithm with large, dense 
matrices is transformed into an algorithm 
with band matrices and computed in an 
array tailored to the band size. This ap¬ 
proach has the potential for high perform¬ 
ance when applicable but is less general 
than the schemes discussed above, because 
the decomposition depends on the algo¬ 
rithm. 


Characteristics of 
array design methods 

Several techniques have been proposed 
for the design of arrays, as reviewed by 
Fortes et al.’ The most successful approach 
has been a transformational paradigm, 
wherein the description of an algorithm is 
successively transformed and made suit¬ 
able for implementation. Let’s examine 
some of the important issues regarding 
transformational methods for the design of 
application-specific arrays. 


Stages in a transformational method. 
We identify two stages in the application 
of a transformational design technique: 
regularization, and derivation of arrays 
(see Figure 10). 

Regularization is the derivation of a 
regularized representation of an algorithm 
from an initial admissible form. This regu¬ 
larized form must provide an implicit or 
explicit description of parallelism in a 
manner suitable for implementation in 
arrays. Moreover, the regularized repre¬ 
sentation must be in a form suitable for ma¬ 
nipulation in the remaining steps of the 
method. 

The second stage, derivation of arrays, 
uses the regular description obtained 
above and determines the topology and 
structure of the array, as well as the charac¬ 
teristics of cells, the flow of data, and the 
I/O. 

The requirements and characteristics 
associated with each stage allow us to 
precisely define and compare the capabili¬ 
ties of different techniques. Within this 
framework the features of a design method 
can be stated in terms of specific factors. In 
the regularization stage these factors are 

• the class of algorithms to which the 
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method can be applied, that is, the 
generality of the initial admissible 
form of the algorithms; 

• the completeness and simplicity of the 
transformations used to produce a 
regular description; and 

• the effectiveness of the regular de¬ 
scription in conveying the properties 
of an algorithm in a form suitable for 
implementation in arrays. 

In the derivation-of-arrays stage these 
factors correspond to the capabilities and 
simplicity of the transformations used to 
derive an array from the regularized form. 
In particular, they include the capabilities 
of the transformations to 

• incorporate implementation con¬ 
straints and restrictions, such as lim¬ 
ited local storage and limited band¬ 
width, into the design; 

• incorporate different attributes of the 
processing elements, such as pipelin¬ 
ing, nonconventional arithmetic, and 
specialized functional units; 

• perform optimization of specific per¬ 
formance measures as part of the de¬ 
sign process; 

• design arrays for fixed-size data and 
partitioned problems; and 

• realize algorithm-specific arrays and 
map algorithms onto class-specific 
arrays. 

An additional factor, applicable to both 
stages, is suitability for automation. 

Representation of regularized algo¬ 
rithms. Transformational approaches dif¬ 
fer. Among these differences are the way a 
regularized description is obtained and 
represented and the capabilities associated 
with the description. In other words, meth¬ 
ods differ in the notation used to represent 
a regularized form and in the suitability of 
the notation to perform transformations to 
derive an array. This notation determines 
the simplicity of the methods as well as the 
guidance provided to select suitable trans¬ 
formations, as discussed below. 

Abstract notations and/or lack of simple 
systematic transformations produce tech¬ 
niques that hide important properties of 
algorithms and implementations, in many 
cases leading to inadequate conclusions 
regarding an algorithm’s features and their 
suitability for a particular array. An ex¬ 
ample is the use of algebraic expressions in 
H.T. Kung’s pioneering work on systolic 
arrays.* Rung concluded that “LU-decom- 
position, transitive closure, and matrix 


multiplication are all defined by recur¬ 
rences of the same ‘type.’ Thus, it is not 
coincidental that they are solved by similar 
algorithms using hexagonal arrays.” 
Moldovan"* made a similar statement 
when describing an algebraic design ap¬ 
proach. However, it has been shown that 
the algorithms for these computations have 
quite different dependency structures, so 
that they are mapped efficiently only onto 
different arrays.’ 

The two most popular types of represen¬ 
tation are algebraic expressions and gra¬ 
phical descriptions.** In algebraic-based 
methods the regularized description is 
given as a set of algebraic expressions, and 
transformations are applied to these ex¬ 
pressions to obtain an implementation. 
Research by Rao and Kailath" provided a 
unifying framework for many of the alge¬ 
braic-based approaches, which basically 
are all techniques derived from Karp, 
Miller, and Winograd’s work.‘^ 

A different line of research uses graphi¬ 
cal notations to describe an algorithm. 
Examples are the signal flow graph 
method’ and our multimesh graph 
method.’ Graph-based methods start by 
representing an algorithm as a graph. 
Transformations are applied on the graph, 
as part of the regularization stage, to render 
it more suitable for later design steps. The 
regularized graph is then mapped (pro¬ 
jected) onto an array either directly or 
through other intermediate representa- 

Many design techniques — algebraic- 
based approaches in particular — have not 
provided specific tools to obtain the corre¬ 
sponding regularized representation. In¬ 
stead they have assumed that this represen¬ 
tation is already available. In cases where 
some attention has been given to the regu¬ 
larizing process, the proposed techniques 
are either ad hoc or heuristic, and the re¬ 
sults obtained are not satisfactory. In other 
words, proposed methods have addressed 
only the second design stage and have 
largely ignored the first. 

For some simple algorithms, such as 
matrix multiplication, finding the regular¬ 
ized version (for example, a regular itera¬ 
tive algorithm" or a uniform recurrence 
equation*’) is straightforward, so that the 
lack of a systematic procedure is not an 
issue. However, simple algorithms are 
relatively few; most matrix algorithms of 
importance (LU-decomposition, QR-de- 
composition, transitive closure, Gaussian 
elimination, and the Faddeev algorithm, 
for example) are not easily described in 
those regularized forms. Moreover, the 


regularized form is often more complex 
than the original algorithm, perhaps hav¬ 
ing additional operations. Specific ex¬ 
amples of these issues are given else¬ 
where.’ 

Limitations of methods in the deriva¬ 
tion of arrays. Each of the previously 
proposed methods has certain limitations 
regarding the derivation of arrays. A 
method may 

• be oriented toward the design of sys¬ 
tolic arrays only, that is, arrays of cells 
with no local storage and high band¬ 
width; 

• assume that all cells in an array are 
identical; 

• have predefined characteristics of 
cells and therefore be unable to incor¬ 
porate other implementation con¬ 
straints or restrictions, such as type of 
cells and I/O bandwidth, into the de¬ 
sign; 

• be unable to analyze trade-offs among 
implementation parameters such as 
amount of local storage and communi¬ 
cation bandwidth of processing ele¬ 
ments; or 

• produce arrays with suboptimal cost 
and/or performance. 

The limitations in regularization and 
realization discussed above motivated 
development of the multimesh graph 
method. 

The multimesh graph 
method 

The class of matrix algorithms suitable 
for the multimesh graph (MMG) method is 
described recursively by an outermost loop 
and a loop body that contains scalar, vec¬ 
tor, and matrix operators, as well as other 
matrix algorithms (see Figure 11). A se¬ 
quence of these algorithms is also a matrix 
algorithm. The operators have the follow¬ 
ing characteristics: 

(1) Scalar, or primitive, operators (such 
as add, multiply, rotation, and sine) are 
basic unary, binary, or ternary operations 
that can produce up to two outputs and 
whose computation time is data independ¬ 
ent. In practice, scalar operators produce a 
single result, except in cases such as rota¬ 
tion of a pair of elements, which produce 
two outputs. 

(2) Vector operators have up to two 
vector operands and produce up to two 
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Figure 12. Dependency graphs of vector operator (a) and matrix operator (b). 


vector results. The same primitive opera¬ 
tor is applied to each element of the vector 
operands to produce the vector results. An 
additional scalar operand is common 
(broadcast) to all instances of the primitive 
operator. Figure 12a shows the depend¬ 
ency graph of a vector operator. 

(3) Matrix operators have up to one 
matrix operand, one vector operand com¬ 
mon to rows of the matrix operator, and a 
second vector operand common to col¬ 
umns of the matrix operator. A matrix 
operator produces a matrix result by apply¬ 
ing the same primitive operator to each 
element of the matrix operand (and associ¬ 
ated elements from the vector operands). 
Figure 12b shows the dependency graph of 
a matrix operator. 

The discussion above shows that vector 


and matrix operators consist of primitive 
operations tied together by the common 
operand(s). Such an operand(s) corre¬ 
sponds to the broadcasting of data through¬ 
out the elements of the vector/matrix. To 
implement these operators in mesh arrays, 
we must eliminate the broadcasted data, 
which is accomplished by applying a trans¬ 
formation (replacing data broadcasting 
with transmitted data). 

Since primitive operators can be unary, 
binary, or ternary, matrix and vector opera¬ 
tors need not have all the operands indi¬ 
cated above. For example, the addition of a 
constant to each element of a vector does 
not use a second vector operand. On the 
other hand, the properties of matrix and 
vector operators rule out performing op¬ 
erations with two matrices or with three 
vectors (that is, adding two matrices or 


rotating elements of two vectors by corre¬ 
sponding angles contained in a third vec¬ 
tor). These operators are not suitable for 
implementation in arrays, because they 
require external data input to inner cells 
(there is no common [broadcasted] data 
that is transferred through cells). For our 
purposes, such cases correspond to sets of 
scalar operations. 

Limitations in the number of inputs and 
outputs to/from the operators in a matrix 
algorithm, as described above, arise from 
the objective of realizing those algorithms 
in mesh arrays. Since cells of arrays have 
only two input and two output ports, plus 
an internal feedback loop, an operator 
cannot have more than three operands. 
Moreover, since the arrays have only near¬ 
est-neighbor connections and external I/O 
only at the boundaries, it is necessary to 
transfer broadcasted data through the cells 
(as transmitted data). Consequently, the 
maximum number of input operands is 
three, and the combined number of com¬ 
puted results and transmitted data output 
from a cell is also limited to three. 

The form of a matrix algorithm, as de¬ 
scribed above, does not place any require¬ 
ments on the way loop indices are used to 
reference the elements of matrices and 
vectors. Two types of references have been 
considered: uniform and affine. With uni¬ 
form references, each loop index used to 
address a variable appears in the form 
(/'-/„) (the index plus/minus a constant). 
Affine references use the more general 
form ((+ i +...+ (a linear combination of 
indices and a constant). Uniform refer¬ 
ences are the more common type and ap¬ 
pear in most matrix algorithms — for 
example, LU-decomposition, QR-decom- 
position, SVD, and transitive closure, to 
name just a few. 

Using uniform or affine references to 
access variables does not imply that the 
algorithm must be a uniform or an affine 
system of equations, as required by other 
methods (particularly algebraic-based 
techniques), such as those described by 
Rao and Kailath" and by Quinton.'^ The 
form of admissible algorithms given here 
is more general than in those cases. For 
example, the MMG method can use the 
transitive closure algorithm as originally 
expressed in Warshall’s algorithm, while 
Rao’s method requires that the algorithm 
be represented as an RIA (regular iterative 
algorithm). Similar situations arise with 
the other methods and algorithms, such as 
LU-decomposition, Gaussian elimination, 
and convolution. 

The canonical form of matrix algorithms 
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shown in Figure 11 and described in the 
previous paragraphs is quite general; for 
instance, it directly accepts the important 
class of matrix algorithms appearing in 
areas such as real-time signal processing.' 
Moreover, algorithms in this class match 
well with implementations as mesh arrays. 
Other representations are also allowed 
with the MMG method, as long as they 
have the type of operators listed earlier and 
are amenable to the transformational pro¬ 
cess. 

Transformational process. The MMG 
method uses a transformational paradigm. 
^ First, a fully parallel data-dependency 
graph (FPG), in which nodes represent op¬ 
erations and edges correspond to data de¬ 
pendencies, is derived from the algorithm. 
We use an FPG because this notation ex¬ 
hibits the intrinsic features of an algo¬ 
rithm. This graph could be used to directly 
derive an implementation by assigning 
each node to a different processing ele¬ 
ment (PE) and by adding delay registers to 
synchronize the arrival of data to PEs. The 
resulting structure (a pipelined realization 
of the graph) exhibits minimum delay 
(determined by the longest path in the 
graph) and optimal throughput (for mul¬ 
tiple-instance computations), but it might 
require nonneighbor and varying-distance 
connections, large I/O bandwidth, and 
many units. The MMG method deals with 
these problems while preserving the fea¬ 
tures inherent in the data-dependency 
graph. 

The two design stages, regularization 
and derivation of arrays, and the steps 
I within them are depicted in the high-level 
description of the MMG method (Figure 
13). The method is described below, where 
we also indicate the suitability for automa¬ 
tion of the different steps involved. More 
details regarding this method and its theo¬ 
retical backing are available.^ 

The regularization stage. The regulari¬ 
zation stage produces a three-dimensional 
graph, which we call a multimesh depend¬ 
ency graph. This graph has the following 
characteristics: 

• unidirectional and nearest-neighbor 
dependencies, 

• edges parallel to axes of the three- 
dimensional space, and 

• nodes at integer values of the axes. 

This regularized form is suitable for the 
derivation of arrays because in addition to 
preserving all the information present in 


the FPG, it has the regular properties that 
characterize mesh arrays. Moreover, as we 
will show, the multimesh dependency 
graph makes it easy to obtain the character¬ 
istics of an array, the schedule of opera¬ 
tions and I/O, and the data transfers. 

Some researchers have regarded the de¬ 
pendency graph of a matrix algorithm as 
multidimensional instead of three dimen¬ 
sional. Such a conclusion was reached by 
representing in a graph the index depend¬ 
encies in the algorithm. In other words, the 
dimensionality of the graph was defined by 
the number of indices appearing in an algo¬ 
rithm. In those approaches every variable 
is required to have all indices, so that each 
instance of a variable is associated with a 
point in the multidimensional index 
space.'"" '^ In contrast, the dimensional¬ 


ity of the data-dependency graph in the 
MMG method is determined by the maxi¬ 
mum of three inputs and three outputs per 
primitive node. A comparison of data 
dependencies and index dependencies, and 
their suitability for a design method, is 
available.’ 

The regularization stage in the MMG 
method is performed in two steps. First, we 
obtain the fully parallel data-dependency 
graph (FPG) of the algorithm. This graph is 
obtained by tracing the execution of the 
algorithm (the outer loop and loop body). 
This means that we symbolically execute 
the algorithm, tracking which variables are 
used and when, and we allocate operations 
to nodes of a graph and data references to 
its edges. In other words, the FPG corre¬ 
sponds to an unfolded dataflow graph. As 
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For k from 1 to n 
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For i from 1 to n 
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Figure 14. Symbolic execution of Warshall’s transitive closure algorithm. 


an example. Figure 14 depicts the sym¬ 
bolic execution of the transitive closure 
algorithm; the resulting FPG is shown in 
Figure 20. The FPG of a small problem (for 
example, n = 4,5) is sufficient to capture 
the features of an algorithm. In addition, 
the FPG consists of several subgraphs with 
the same dependency structure but perhaps 
different in size. 

Second, we transform the fully parallel 
data-dependency graph into a three-di¬ 
mensional multimesh graph, like those in 
Figure 15. To do this, we perform transfor¬ 
mations on the FPG to remove properties 
not allowed in MMGs. The complete set of 
such properties consists only of 

• data broadcasting, which is replaced 
by transmitted data; 

• bidirectional dataflow, which is elimi¬ 
nated by moving dependent operations 


to one side of the data source; and 
• nonregular dependencies, which are 
removed by adding delay nodes in the 
nonregular part. 

A detailed discussion of these transforma¬ 
tions is available.’ They are illustrated in 
the next section through their application 
to the transitive closure algorithm. 

Derivation of arrays. To perform the 
second stage in the MMG method, we 
collapse the MMG onto a two-dimensional 
G-graph. We do this by grouping prisms of 
primitive nodes — of base size phy q — 
onto G-nodes (see Figure 16). These 
prisms extend along one complete axis of 
the MMG. Grouping prisms parallel to 
axes of the three-dimensional space leads 
to simpler and more efficient implementa¬ 
tions, so that the direction of collapse can 


be limited to three alternatives, one along 
each axis. 

Selecting prisms of base size 1 by 1 
leads to systolic arrays. This particular 
grouping corresponds to projecting the 
MMG onto a two-dimensional G-graph. 

Next we schedule the order of execution 
for primitive operations that compose a G- 
node. 

The size and schedule of prisms deter¬ 
mine such cell properties as size of local 
storage, communication bandwidth, and 
cell pipelining. Scheduling operations by 
following the flow of transmitted data (see 
Figure 17) permits efficient use of pipe¬ 
lined cells. Scheduling by meshes of primi¬ 
tive nodes of size p by q, also depicted in 
Figure 17, minimizes the local storage 
required. (With prisms of base size 1 by 1, 
the only schedule possible is determined 
by the dependencies.) The cell bandwidth 
is determined by the number of edges that 
intersect a prism’s side (the difference 
between cell bandwidth and functional unit 
bandwidth is adjusted by the queues at¬ 
tached to ports). Consequently, trade-offs 
make it possible to select prism size ac¬ 
cording to specific implementation re¬ 
quirements. Moreover, grouping is driven 
by the target implementation, which can be 
an algorithm-specific array for fixed-size 
data, a partitioned implementation, or a 
mapping onto a class-specific array. Con¬ 
sequently, the two steps above make it 
possible to optimize specific measures on 
the basis of implementation constraints. 

For problems with fixed-size data on 



Figure 15. Examples of multimesh graphs: (a) complete multimesh data-dependency graph; (b) incomplete multimesh 
data-dependency graphs. 
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two-dimensional structures, we realize the 
G-graph obtained above as an array by 
allocating each G-node to a different pro¬ 
cessing element and each edge to a differ¬ 
ent communication link. 

For problems with fixed-size data on 
linear arrays, we apply cut-and-pile to the 
G-graph. Each partition corresponds to a 
complete horizontal or vertical path of the 
G-graph. Nodes in a partition, or a cut, are 
executed concurrently, while different 
partitions are scheduled (piled) for pipe¬ 
lined execution in the array. Each G-node 
in a cut is allocated to a different process¬ 
ing element and each edge to a different 
communication link. 

For partitioned problems we first divide 
(cut) the G-graph into sets of neighbor G- 
nodes (G-sets), with each G-set having as 
many nodes as there are cells in the array. 
Nodes in a G-set are structured in a linear 
or two-dimensional manner, depending on 
the desired array topology, and they are 
executed concurrently in the array. Figure 
18 illustrates this process and the corre¬ 
sponding arrays. Data flowing between G- 


sets is stored in and retrieved from memo¬ 
ries external to the array, as Figure 18 
shows. 


Next we schedule (pile) G-sets for exe¬ 
cution. G-sets are executed in an over¬ 
lapped (pipelined) manner, as Figure 19 
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Figure 18. Applying cut-and-pile to the G-graph and corresponding arrays: (a) a linear array; (b) a two-dimensional array. 
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Figure 19. Overlapped execution of G-sets in a linear array. 


shows for a linear array. While one set is 
executing, the input data for the next set is 
transferred from the host through the I/O 


structure shown at the top of the array in 
Figure 18. At the same time, the results 
from the previous G-set are returned to the 


host through the same structure. 

For mapping onto class-specific arrays, 
we first divide (cut) the G-graph into sets 
of neighbor G-nodes (G-sets) whose char¬ 
acteristics (number and topology of nodes) 
are determined by characteristics of the 
specific array. Then we schedule (pile) G- 
sets for execution. 

In all of the above cases, the array I/O 
schedule is determined by the schedule of 
the G-sets (if applicable) and by the arri¬ 
val/departure of data to/from G-nodes. In 
particular, large partitioned problems lead 
to scheduling of G-sets in the same man¬ 
ner, so that the arrays depicted in Figure 18 
correspond to canonical architectures for 
partitioned execution of algorithms. 

The steps in the regularization stage and 
in the derivation of arrays can be per¬ 
formed automatically. However, implem¬ 
entation of certain steps might be simpli¬ 
fied by capitalizing on the graphic charac¬ 
teristics of the method in an interactive 
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CAD tool (for example, it is easier to visu¬ 
alize broadcasted data in a graph represen¬ 
tation than to determine it automatically). 

Performance and cost measures. 
There is no single suitable measure of 
performance and cost for application-spe¬ 
cific implementations. In some cases the 
number of cells may be important, while in 
others the stress may be on throughput or 
utilization of cells. Therefore, to deter¬ 
mine the performance of arrays derived 
with the MMG method, we use the follow¬ 
ing set of measures (where N is the number 
of operations in the algorithm); 

T Throughput 

K Number of cells 

U Utilization {U = NIKT') 


Aiig Input/output bandwidth 
Storage per cell 
Cell bandwidth 

Other measures can also be defined by a 
designer, depending on the requirements 
of particular applications. The measures 
are computed with information obtained 
from the dependency graphs, both the 
original fully parallel graph and the trans¬ 
formed graphs. Moreover, transformations 
used in the method affect such measures, 
so that one can study the impact of a par¬ 
ticular transformation on the resulting 
array’s cost and performance while carry¬ 
ing out the transformation. The next sec¬ 
tion provides examples of these issues as 
the MMG method is applied to a specific 
algorithm. 


Example application 
of the MMG method 

We can observe the MMG method 
through the derivation of mesh arrays for 
the transitive closure algorithm. 

The regularization process. Figure 14 
shows Warshall’s algorithm to compute 
the transitive closure. It consists of three 
nested loops and a single-assignment state¬ 
ment. Although it looks very similar to 
matrix multiplication, the order of the loop 
indices is reversed, so that the dependen¬ 
cies are different. 

Figure 20 depicts the fully parallel graph 
for a problem of size n = 4, obtained from 
the symbolic execution of Warshall’s algo- 
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Figure 21. Replacing broadcasting with transmitted data. 


rithm. This FPG is characterized by many 
broadcasted elements and many superflu¬ 
ous operations (highlighted in the figure) 
where the result is equal to one of the input 
operands. This property, a consequence of 


primitive operations AND and OR, is 
dependent on the specific algorithm, but it 
illustrates the capabilities of an explicit 
description. Superfluous operations can be 
removed if it is advantageous for an im¬ 


plementation (that is, if it simplifies the 
resulting array). 

The FPG shown in Figure 20 consists of 
n levels, with each level corresponding to 
one iteration of the outermost loop in 


46 


COMPUTER 





























































































Warshall’s algorithm. At each level there 
is global and local broadcasting. Global 
broadcasting corresponds to data that is 
broadcast throughout the entire level, 
while locally broadcast data reaches only a 
portion of the level. Sources of broadcast¬ 
ing change from level to level; at the ^h 
level of the graph the /dh row of matrix 
data, as well as the ^h element of each row, 
is broadcast. 

As indicated earlier, regularizing the 
graph in Figure 20 consists of replacing 
data broadcasting with transmitted data, 
drawing the graph as a three-dimensional 
structure, removing bidirectional flow of 
transmitted data, and adding delay nodes 
to make sure that all dependencies are 
among nearest-neighbor nodes (in other 
words, regular). Let’s examine this pro¬ 
cess. 

First we transform the FPG by replacing 
data broadcasting with transmitted data. 


Globally broadcast data is drawn orthogo¬ 
nal to the flow of locally broadcast ele¬ 
ments, in a three-dimensional structure. 
The resulting three-dimensional graph, 
shown in Figure 21, does not fulfill the 
requirements of an MMG, because it ex¬ 
hibits bidirectional flow of transmitted 
data. This graph has the same dependency 
structure as the one used in the signal flow 
graph (SFG) method.* However, the graph 
derived with the SFG method requires re¬ 
writing the algorithm in a single-assign¬ 
ment form, which is not necessary with the 
MMG method. Moreover, nodes in the 
graph derived with the MMG method 
compute only one variable, whereas the 
single-assignment form produces nodes 
that compute three variables. 

Bidirectional transmitted data can be 
eliminated if all nodes at one side of the 
data source are part of a movable sub¬ 
graph.^ The graph in Figure 21 fulfills this 


requirement, so that nodes are moved to 
one side of the transmitted data sources in 
two steps; 

(1) Nodes to the left of sources of hori¬ 
zontal transmitted data are moved to the 
right end of each level of the graph, as 
Figure 22a shows; application of this 
transformation leads to the graph in Figure 
23. 

(2) Nodes in front of sources of trans¬ 
mitted data along the z axis are moved to 
the end of this axis, as Figure 22b shows, 
resulting in the graph of Figure 24. 

Figure 24 still exhibits one characteris¬ 
tic not allowed in a multimesh depend¬ 
ency graph: Dependencies between nodes 
at the boundaries of the three-dimensional 
structure are not between nearest neigh¬ 
bors. This irregularity is eliminated by 
adding delay nodes in the vacant posi- 
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Figure 24. A unidirectional dependency graph. 
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tions, leading to the multimesh depend¬ 
ency graph shown in Figure 25. In this 
figure we have also replaced superfluous 
nodes with delay nodes. 

From this example we can infer that the 
MMG is advantageous in describing an 
algorithm because it provides information 
on all operations and dependencies with¬ 
out imposing constraints on the 
algorithm’s form. Moreover, an algorithm 
described by an FPG is transformed into a 
regular MMG in a simple and systematic 
manner by using a set of predefined trans¬ 
formations and taking advantage of the 
graphics capabilities offered by the data 
dependencies. 

Derivation of arrays. To simplify the 
discussion, we consider grouping by 
prisms of base size 1 by 1 (that is, grouping 
for systolic arrays). In Figure 26 we project 
the MMG of transitive closure along the 
three axes, producing three G-graphs. 
(Literature is available describing the more 
general case of grouping by prisms.’) 

For problems with fixed-size data, the 
G-graphs are directly realized as arrays. 
Three structures are obtained; Table 1 
summarizes their performance and cost 
characteristics. These measures are ob¬ 
tained from the MMG and the correspond¬ 
ing G-graph. For example, the number of 
cells is equal to the number of G-nodes, 


throughput is given by the largest number 
of operation nodes grouped into a single G- 
node, and utilization of cells is related to 
the length of paths in the MMG (or the 
number of primitive nodes per prism). 


The graphs also allow us to compare the 
performance and cost of the different re¬ 
sulting structures. For example, grouping 
prisms parallel to the y axis is not conven¬ 
ient, because paths have different lengths. 



Figure 26. Projecting the multimesh graph onto G-graphs. 
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Table 1. Cost and performance measures of arrays for transitive closure. 


Array 

Throughput 

Opers. 

Number of 

Number of 

Links 



per cell 

cells 

regs 

per cell 

X-grouping 

Mn 

1 

n(n-l) 

(n-1) 

4 

F-grouping 

1/n 

1 

3n^-5n-b2 

(4n -2) 

4 

Z-grouping 

1/n 

1 


2n 

4 

Rao’s method 

1/n 

3 

~3n^ 


4 

SFG method 

Mn 

3 



8 


leading to nonoptimal utilization of cells. 
On the other hand, grouping parallel to axis 
X or z collapses paths of the same length, 
with the associated benefits in utilization. 
Complete details on the performance of 
these arrays are reported elsewhere, as is a 
comparison with other arrays previously 
proposed for the same algorithm.’ Table 1 
also summarizes the data corresponding to 
arrays derived with two other methods. 

As indicated earlier, partitioned prob¬ 
lems lead to the canonical structures de¬ 
picted in Figure 18. For partitioning, the G- 
graphs derived by grouping prisms parallel 
to axis X or z are more convenient because 
both resulting graphs have G-nodes with 
the same computation time. 


T he MMG method incorporates 
features not available in other 
previously proposed techniques. 
These features include a general class of 
admissible algorithms; transformations to 
regularize algorithms; and transformations 
to derive arrays, given implementation 
constraints. This method is applicable to a 
large class of frequently used matrix com¬ 
putations, including the algorithms de¬ 
scribed by Speiser and Whitehouse,' 
Derivation of arrays in the MMG 
method is systematic, flexible, and suited 
for obtaining mesh structures, taking into 
account architectural features, implemen¬ 
tation constraints, and performance and 
cost measures. Moreover, the method has 
resulted in application-specific arrays with 
fewer, simpler, and better utilized cells 
than arrays previously proposed for the 
same algorithms. ■ 
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Real-Time Scheduling 
Theory and Ada* 


Lui Sha and John B. Goodenough 
Software Engineering Institute, Carnegie Mellon University 


I n real-time applications, the correct¬ 
ness of computation depends on not 
only the results of computation but 
also the time at which outputs are gener¬ 
ated. Examples of real-time applications 
include air traffic control, avionics, pro¬ 
cess control, and mission-critical compu¬ 
tations. 

The measures of merit in a real-time 
system include 

• Predictably fast response to urgent 
events. 

• High degree of schedulability. 
Schedulability is the degree of re¬ 
source utilization at or below which 
the timing requirements of tasks can be 
ensured. You can think of it as a mea¬ 
sure of the number of timely transac¬ 
tions per second. 

• Stability under transient overload. 
When the system is overloaded by 
events and meeting all deadlines is 
impossible, we must still guarantee the 
deadlines of selected critical tasks. 

Traditionally, many real-time systems 
use cyclical executives to schedule con¬ 
current threads of execution. Under this 
approach, a programmer lays out an execu¬ 
tion timeline by hand to serialize the exe¬ 
cution of critical sections and to meet task 
deadlines. 

While such an approach is manageable 
for simple systems, it quickly becomes 


E~ " ' - . ' 

Rate monotonic 
scheduling theory 
puts real-time software 
engineering on a sound 
analytical footing. 
Here, we review the 
theory and its 
implications for Ada. 


unmanageable for large systems. It is a 
painful process to develop application 
code so that it fits the time slots of a 
cyclical executive while ensuring that the 
critical sections of different tasks do not 
interleave. Forcing programmers to sched¬ 
ule tasks by fitting code segments on a time¬ 


* This article is a modified version of a technical report, 
CMU/SEI-89-TR-14, sponsored by the US Dept, of 
Defense and bearing the same title. 


line is no better than the outdated approach 
of managing memory by manual memory 
overlay. 

Under the cyclical executive approach, 
meeting the responsiveness, schedulabil¬ 
ity, and stability requirements has become 
such a difficult job that practitioners often 
sacrifice program structure to fit the code 
into the “right” time slots. This results in 
real-time programs that are difficult to 
understand and maintain. 

The Ada tasking model represents a 
fundamental departure from the cyclical 
executive model. To reduce the complex¬ 
ity of developing a concurrent system, Ada 
tasking allows software engineers to man¬ 
age concurrency at an abstract level di¬ 
vorced from the details of task executions. 
Indeed, the dynamic preemption of tasks at 
runtime generates nondeterministic time¬ 
lines at odds with the very idea of a fixed 
execution timeline. 

This nondeterminism seems to make it 
impossible to decide whether real-time 
deadlines will be met. However, Ada’s 
tasking concepts are well-suited to the rate 
monotonic theory being considered in our 
project. 

In essence, this theory ensures that as 
long as the CPU utilization of all tasks lies 
below a certain bound and appropriate 
scheduling algorithms are used, all tasks 
will meet their deadlines without the pro¬ 
grammer knowing exactly when any given 
task will be running. Even if a transient 
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Example 1‘. Consider the case of three 
periodic tasks, where U. = C. IT.. 



overload occurs, a fixed subset of critical 
tasks will still meet their deadlines as long 
as their CPU utilizations lie within the 
appropriate bound. 

In short, the scheduling theory allows 
software engineers to reason about timing 
correctness at the same abstract level used 
by the Ada tasking model. Applying this 
theory to Ada makes Ada tasking truly 
useful for real-time applications while also 
putting the development and maintenance 
of real-time Systems on an analytic, engi¬ 
neering basis, making these systems easier 
to develop and maintain. 

The next section reviews some of the 
basic results in the rate monotonic schedul¬ 
ing theory, although the theory also deals 
with mode changes and multiprocessing. 

In the final section, we review the Ada 
tasking model and scheduling policies, and 
suggest some workarounds that permit us 
to implement rate monotonic scheduling 
algorithms within the framework of exist¬ 
ing Ada rules. 

Scheduling real-time 
tasks 

This section contains an overview of 
some of the important issues of real-time 
scheduling theory, beginning with the 
problem of ensuring that independent peri¬ 
odic tasks meet their deadlines. Then, we 
show how to ensure that critical tasks will 
meet their deadlines even when a system is 
temporarily overloaded, address the prob¬ 
lem of scheduling both periodic and aperi¬ 


odic tasks, and review real-time synchro¬ 
nization and communication issues. 

Periodic tasks. Tasks are independent 
if their executions need not be synchro¬ 
nized. Given a set of independent periodic 
tasks, the rate monotonic scheduling algo¬ 
rithm gives each task a fixed priority and 
assigns higher priorities to tasks with 
shorter periods. A task set is said to be 
schedulable if all its deadlines are met, that 
is, if every periodic task finishes its execu¬ 
tion before the end of its period. Any set of 
independent periodic tasks is schedulable 
by the rate monotonic algorithm if the 
condition of Theorem 1 is met.^ 

Theorem 7: A set of n independent 
periodic tasks scheduled by the rate 
monotonic algorithm will always meet 
its deadlines, for all task phasings, if 

!!•+...+^<n(2*/''-l) = t/(n) 

where C. and T. are the execution time 
and period of task i., respectively. 

Theorem 1 offers a sufficient (worst- 
case) condition that characterizes schedul- 
ability of a task set under the rate mono¬ 
tonic algorithm. This bound converges to 
69 percent (In 2) as the number of tasks 
approaches infinity. The values of the 
scheduling bounds for one to nine inde¬ 
pendent tasks are as follows: U(l) = 1.0, 
U(2) = 0.828, U(3) = 0.779, U(4) = 0.756, 
U(5) = 0.743, U(6) = 0.734, U(7) = 0.728, 
U(8) = 0.724, and U(9) = 0.720. 


• Task X,: C, = 20 ; T, = 100 ; U, = 0.2 

• Task x^: = 40 ; = 150 ; = 0.267 

• Task X3: C3 = 100; Tj = 350; 1/3 = 0.286 

The total utilization of these three tasks 
is 0.753, which is below Theorem I’s 
bound for three tasks: 3(2'^ - 1) = 0.779. 
Hence, we know these three tasks are 
schedulable, that is, they will meet their 
deadlines if x, is given the highest priority, 
Xj the next highest, and X3 the lowest. 

The bound of Theorem 1 is very pessi¬ 
mistic because the worst-case task set is 
contrived and unlikely to be encountered 
in practice. For a randomly chosen task set, 
the likely bound is 88 percent.'* To know if 
a set of given tasks with utilization greater 
than the bound of Theorem 1 can meet its 
deadlines, we can use an exact schedula- 
bility test based on the critical zone theo¬ 
rem (rephrased from Liu and Layland^): 

Theorem 2: For a set of independent 
periodic tasks, if each task meets its 
first deadline when all tasks are started 
at the same time, then the deadlines 
will always be met for any combina¬ 
tion of start times. 

This theorem provides the basis for an 
exact schedulability test for sets of inde¬ 
pendent periodic tasks under the rate 
monotonic algorithm. In effect, the theo¬ 
rem requires that we check to see if each 
task can complete its execution before its 
first deadline. To do so, we need to check 
the scheduling points for a task. The sched¬ 
uling points for task x are x’s first deadline 
and the ends of periods of higher priority 
tasks prior to x’s first deadline. The pro¬ 
cess is illustrated by Figure 1, which ap¬ 
plies to the task set in the next example. 

Example 2: Suppose we replace x,’s 
algorithm in Example 1 with one that is 
more accurate and computationally inten¬ 
sive. Suppose the new algorithm doubles 
X, ’s computation time from 20 to 40, so the 
total processor utilization increases from 
0.753 to 0.953. Since the utilization of the 
first two tasks is 0.667, which is below 
Theorem I’s bound for two tasks, 2(2'^ 
-1) = 0.828, the first two tasks cannot miss 
their deadlines. For task Xj, we use Theo¬ 
rem 2 to check whether the task set is 
schedulable. Figure 1 shows the schedul¬ 
ing points relevant to task Xj, that is, the 
ends of periods of higher priority tasks for 
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Table 1. Minor cycle timeline for Example 2. Each minor cycle is SO. 


times less than or equal to T^’s period. To 
check against the critical zone theorem, we 
check whether all tasks have completed 
their execution at any of the scheduling 
points. For example, to see if all tasks have 
met their deadlines at time 350, we can see 
that task Tj will have had to start executing 
four times; task three times; and task Tj, 
once. So we check to see if all these execu¬ 
tions can complete in 350 milliseconds; 

4C, + 3C^ + C^<T^ 

160 + 120 -t- 100 > 350 

This test fails, but that doesn’t mean the 
task set can’t meet its deadlines; the theo¬ 
rem requires that all the scheduling points 
be checked. If all tasks meet their dead¬ 
lines for at least one scheduling point, the 
task set is schedulable. The equations to be 
checked are shown below, for each sched¬ 
uling point; 

c, + Cj + C3 < r, 

40-1-40-I- 100 > 100 

2C, -1- Cj C3 < Tj 

80-1-40-1- 100 > 150 

2C, -1- 2C3 -I- C3 < 27, 

80-1-80-1- 100 > 200 

3C, + 2C3 + C3 < 2T^ 

120-1-80-1- 100 = 300 

4C, -I- 3C3 + C3 < 73 

160-I- 120-I- 100 > 350 

The equation for scheduling point 27^ is 
satisfied. That is, after 300 units of time, t, 
will have run three times, will have run 
twice, and X3 will have run once. The re¬ 
quired amount of computation just fits 
within the allowed time, so each task meets 
its deadline. Liu and Layland^ showed that 
since the tasks meet their deadlines at least 
once within the period Ty they will always 
meet their deadlines. Hence, we can double 
the utilization of the first task in Example 
1 from 20 percent to 40 percent and still 
meet all the deadlines. Since task X3 just 
meets its deadline at time 300, we cannot 
add any tasks with a priority higher than 
that of task x,, although a task of lower 
priority could be added if its period is 
sufficiently long. 

The checking required by Theorem 2 
can be represented by an equivalent mathe¬ 
matical test'*: 

Theorem 3: A set of n independent 
periodic tasks scheduled by the rate 


monotonic algorithm will always meet 
its deadlines, for all task phasings, if 
and only if 

Vi, !</<«, 

{k,l) ERi lf\ - 1 

where C and Tj are the execution time 
and period of task x., respectively, and 

R. ={(k,l) \l<k<i,l=\, ...,Lt /7j}. 

A major advantage of using the rate 
monotonic algorithm is that it allows us to 
follow the software engineering principle 
of separation of concerns. In this case, the 
theory allows systems to separate concerns 
for logical correctness from concerns for 
timing correctness. 

Suppose a cyclical executive is used for 
this example. The major cycle must be the 
least common multiple of the task periods. 
In this example, the task periods are in the 
ratio 100:150:350 = 2:3:7. A minor cycle 
of 50 units would induce a major cycle of 
42 minor cycles, which is an overly com¬ 
plex design. 

To reduce the number of minor cycles, 
we can try to modify the periods. For ex¬ 
ample, it might be possible to reduce the 
period of the longest task, from 350 to 300. 
The total utilization is then exactly 100 
percent, and the period ratios are 2:3:6; the 
major cycle can then be six minor cycles of 
50 units. 

To implement this approach and mini¬ 
mize the splitting of computations belong¬ 
ing to a single task, we could split task x, 
into two parts of 20 units computation 
each. The computation of task X2 similarly 
could be split into at least two parts such 
that task X3 need only be split into four 
parts. A possible timeline indicating the 
amount of computation for each task in 
each minor cycle is shown in Table 1, 
where 20, on the first line indicates the first 
part of task X|’s computation, which takes 
20 units of time. 


When the processor utilization level is 
high and many tasks need to be performed, 
fitting code segments into time slots can be 
a time-consuming iterative process. In 
addition, a later modification of any task 
may overflow a particular minor cycle and 
require the entire timeline to be redone. 

But more importantly, the cyclic execu¬ 
tive approach has required us to modify the 
period of one of the tasks, increasing the 
utilization to 100 percent without in fact 
doing more useful work. Under the rate 
monotonic approach for this example, all 
deadlines are met, but total machine utili¬ 
zation must not exceed 95.3 percent in¬ 
stead of 100 percent. 

This doesn’t mean the rate monotonic 
approach is less efficient. The capacity not 
needed to service real-time tasks in the rate 
monotonic approach can be used by back¬ 
ground tasks, for example, for built-in-test 
purposes. With the cyclic executive ap¬ 
proach, no such additional work can be 
done in this example. 

Control applications typically require 
that signals be sent and received at fixed 
intervals with minimal jitter, that is, with 
precise timing in sending or receiving data. 
Jitter requirements are a special kind of 
deadline requirement. 

One way of meeting an output jitter 
requirement using rate monotonic schedul¬ 
ing is to have a normal periodic task com¬ 
pute a result and place it in a memory- 
mapped I/O buffer before it is time to send 
the value. Rate monotonic scheduling theo¬ 
rems can be used to ensure the value is 
computed in time. A hardware timer or the 
operating system clock interrupt handler 
routine can then initiate the device I/O 
precisely at the required time. A similar 
approach can be used for input jitter re¬ 
quirements. 

Stability under transient overload. So 

far, we have assumed that the computation 
time of a task is constant. However, in 
many applications, task execution times 
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Figure 2. Example of deadlock prevention. The gray section shows the interval of 
time when the priority ceiling protocol prevents task T1 from locking semaphore 
SI or semaphore S2. 


are often stochastic, and the worst-case 
execution time can be significantly larger 
than the average execution time. 

To have a reasonably high average pro¬ 
cessor utilization, we must deal with the 
problem of transient overload. We con¬ 
sider a scheduling algorithm to be stable if 
a set of tasks exists such that all tasks in the 
set will meet their deadlines even if the 
processor is overloaded. 

This means that, under worst-case con¬ 
ditions, tasks outside the set may miss their 
deadlines. The rate monotonic algorithm is 
stable — the tasks guaranteed to meet their 
deadlines under worst-case execution 
times are always the n highest priority 
tasks. These tasks form the schedulable 
task set. Software designers, therefore, 
must be sure that all tasks whose deadlines 
must be met under overload conditions are 
in the schedulable set. 

Since task priorities are assigned ac¬ 
cording to the period of each task, a criti¬ 
cally important task might not be in the 
schedulable set. A task with a longer pe¬ 
riod could be more critical to an applica¬ 
tion than a task with a shorter period. You 
might try to ensure that such a task always 
meets its deadline simply by increasing its 
priority to reflect its importance. However, 
this approach makes it more likely that 
other tasks will miss their deadlines, that 
is, the schedulability bound is lowered. 

The period transformation technique 
can be used to ensure high utilization while 
meeting the deadline of an important, long- 
period task. For example, suppose task t 
with a long period T is not guaranteed to 


meet its deadline under transient overload 
conditions, but nonetheless, the work per¬ 
formed by the task is critical, and it must 
never miss its deadline. 

We need to ensure that task t belongs to 
the schedulable task set. Since the rate 
monotonic priority of a task is a function of 
its period, we can raise task t’s priority 
only by having it act like a task with a 
shorter period. We can do so by giving it a 
period of r/2 and suspending it after it 
executes half its worst-case execution 
time, C/2. 

The task is then resumed and finishes its 
work in the next execution period. It still 
completes its total computation before the 
end of period T. From the viewpoint of the 
rate monotonic theory, the transformed 
task has the same utilization but a shorter 
period, 7/2, and its priority is raised ac¬ 
cordingly. Note that the most important 
task need not have the shortest period. We 
only need to make sure that it is in the 
schedulable set. A systematic procedure 
for period transformation with minimal 
task partitioning can be found in Sha, 
Lehoczky, and Rajkumar.^ 

Period transformation resembles the 
task slicing found in cyclic executives. The 
difference here is that we don’t need to 
adjust the code segment sizes so different 
code segments fit into shared time slots. 
Instead, T simply requests suspension after 
performing C/2 amount of work. Alterna¬ 
tively, the runtime scheduler can be in¬ 
structed to suspend the task after C/2 work 
has been done, without affecting the appli¬ 
cation code. 


Scheduling both aperiodic and peri¬ 
odic tasks. It is important to meet both the 
regular deadlines of periodic tasks and the 
response time requirements of aperiodic 
requests. Aperiodic servers are tasks used 
to process such requests. Here is a simple 
example. 

Examples-. Suppose we have two tasks. 
Let be a periodic task with period 100 
and execution time 99. Let be a server 
for an aperiodic request that randomly 
arrives once within a period of 100. Sup¬ 
pose one unit of time is required to service 
one request. 

If we let the aperiodic server execute 
only in the background, that is, only after 
completing the periodic task, the average 
response time is about 50 units. The same 
can be said for a polling server that pro¬ 
vides one unit of service time in a period of 
100 . 

On the other hand, we can deposit one 
unit of service time in a “ticket box” every 
100 units of time; when a new “ticket” is 
deposited, the unused old tickets, if any, 
are discarded. With this approach, no 
matter when the aperiodic request arrives 
during a period of 100, it will find a ticket 
for one unit of execution time at the ticket 
box. That is, can use the ticket to preempt 
X, and execute immediately when the re¬ 
quest occurs. In this case, x^’s response 
time is precisely one unit and the deadlines 
of X, are still guaranteed. 

This is the idea behind a class of aperi¬ 
odic server algorithms* that can reduce 
aperiodic response time by a large factor (a 
factor of 50 in this example). We allow the 
aperiodic servers to preempt the periodic 
tasks for a limited duration allowed by the 
rate monotonic scheduling formula. 

A good aperiodic server algorithm is 
known as the sporadic server.’ Instead of 
refreshing the server’s budget periodi¬ 
cally, at fixed points in time, replenish¬ 
ment is determined by when requests are 
serviced. In the simplest approach, the 
budget is refreshed T units of time after it 
has been exhausted, but earlier refreshing 
is also possible. 

A sporadic server is only allowed to 
preempt the execution of periodic tasks as 
long as its computation budget is not ex¬ 
hausted. When the budget is used up, the 
server can continue to execute at back¬ 
ground priority if time is available. When 
the server’s budget is refreshed, its execu¬ 
tion can resume at the server’s assigned 
priority. 

There is no overhead if there are no 
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requests. Therefore, the sporadic server is 
especially suitable for handling emergency 
aperiodic events that occur rarely but must 
be serviced quickly. 

From a schedulability point of view, a 
sporadic server is equivalent to a periodic 
task that performs polling. That is, we can 
place sporadic servers at various priority 
levels and use only Theorems 1 and 2 to 
perform a schedulability analysis. With 
this approach, both periodic and aperiodic 
task modules can be modified at will, as 
long as the rate monotonic utilization 
bound is observed. 

When the average aperiodic workload is 
no more than 70 percent of the CPU capac¬ 
ity allocated for the sporadic server, ran¬ 
domly arriving requests are likely to find 
the server available and can successfully 
preempt the periodic tasks. This results in 
about 6 times faster response than polling 
and 10 times faster response than back¬ 
ground service.’ 

When the aperiodic workload is about 
equal to the server’s budget, the likelihood 
of server availability decreases and the 
resulting performance advantage also de¬ 
creases. The performance of such an over¬ 
loaded server is essentially that of a polling 
server. 

Finally, sporadic servers can be used to 
service hard-deadline aperiodic requests. 
An example will be given in the section 
“An example of application of the theory.” 


Task synchronization. In previous 
sections, we discussed the scheduling of 
independent tasks. Tasks, however, do 
: interact. In this section, we discuss how the 

' rate monotonic scheduling theory can be 
■ applied to real-time tasks that must inter- 
I act. The discussion is limited in this article 
to scheduling within a uniprocessor. Read¬ 
ers interested in the multiprocessor syn¬ 
chronization problem should see 
Rajkumar, Sha, and Lehoczky.' 

Common synchronization primitives in¬ 
clude semaphores, locks, monitors, and 
Ada rendezvous. Although the use of these 
or equivalent methods is necessary to en¬ 
sure the consistency of shared data or to 
guarantee the proper use of non- 
preemptable resources, their use may jeop¬ 
ardize the ability of the system to meet its 
timing requirements. In fact, a direct appli¬ 
cation of these synchronization mecha¬ 
nisms may lead to an indefinite period of 
priority inversion, which occurs when a 
high-priority task is prevented from exe¬ 
cuting by a low-priority task. Unbounded 
priority inversion can occur as shown in 
the following example: 


Example 4: Suppose periodic tasks Tl, 
T2, and T3 are arranged in descending 
order of priority (high, medium, and low). 
Suppose tasks Tl and T3 share a data 
structure guarded by semaphore SI. Dur¬ 
ing the execution of the critical section of 
task T3, high-priority task Tl starts to 
execute, preempts T3, and later attempts to 
use the shared data. However, Tl is 
blocked on the semaphore S1. 

We would prefer that T1, being the high¬ 
est priority task, be blocked no longer than 
the time it takes for T3 to complete its 
critical section. However, the duration of 
blocking is, in fact, unpredictable. This is 
because T3 can be preempted by the me¬ 
dium priority task T2. Tl will be blocked, 
that is, prevented from executing, until T2 
and any other pending tasks of intermedi¬ 
ate priority are completed. 

The problem of unbounded priority 
inversion can be partially remedied in this 
case if a task is not allowed to be preempted 
while executing a critical section. How¬ 
ever, this solution is only appropriate for 
very short critical sections because it cre¬ 
ates unnecessary priority inversion. For 
instance, once a low-priority job enters a 
long critical section, a high priority job that 
does not access the shared data structure 
may be needlessly blocked. 

The priority ceiling protocol is a real¬ 
time synchronization protocol with two 
important properties: 

(1) freedom from mutual deadlock and 

(2) bounded priority inversion. 
Namely, at most one lower priority 
task can block a higher priority 
task.*'* 

There are two ideas in the design of this 
protocol. First is the concept of priority 
inheritance: when a task x blocks the exe¬ 
cution of higher priority tasks, task x exe¬ 
cutes at the highest priority level of all the 
tasks blocked by x. Second, we must guar¬ 
antee that a critical section is allowed to 
start execution only if the section will 
always execute at a priority level higher 
than the (inherited) priority levels of any 
preempted critical sections. 

It was shown in Sha, Rajkumar, and 
Lehoczky’ that such a prioritized total 
ordering in the execution of critical sec¬ 
tions leads to the two desired properties. 
To achieve such a prioritized total order¬ 
ing, we define the priority ceiling of a 
binary semaphore S to be the highest prior¬ 
ity of all tasks that may lock S. 

When a task x attempts to execute one of 


its critical sections, it will be suspended 
unless its priority is higher than the priority 
ceilings of all semaphores currently locked 
by tasks other than x. If task x is unable to 
enter its critical section for this reason, the 
task that holds the lock on the semaphore 
with the highest priority ceiling is said to 
be blocking x and, hence, inherits the prior¬ 
ity of X. As long as a task x is not attempting 
to enter one of its critical sections, it will 
preempt every task that has a lower prior¬ 
ity. 

The priority ceiling protocol guarantees 
that a high-priority task will be blocked by 
at most one critical region of any lower 
priority task. Moreover, the protocol pre¬ 
vents mutual deadlock, as shown in the 
following example: 

Example 5: Suppose we have two tasks 
Tl and T2 (see Figure 2). In addition, there 
are two shared data structures protected by 
binary semaphores SI and S2, respec¬ 
tively. Suppose task Tl locks the sema¬ 
phores in the order SI, S2, while T2 locks 
them in the reverse order. Further, assume 
that Tl has a higher priority than T2. 

Since both T1 and T2 use semaphores S1 
and S2, the priority ceilings of both sema¬ 
phores are equal to the priority of task Tl. 
Suppose that at time t^, T2 begins execu¬ 
tion and then locks semaphore S2. At time 
fj, task Tl is initiated and preempts task 
T2, and at time t^, task Tl tries to enter its 
critical section by attempting to lock sema¬ 
phore SI. However, the priority of Tl is 
not higher than the priority ceiling of 
locked semaphore S2, Hence, task Tl must 
be suspended without locking SI. Task T2 
now inherits the priority of task Tl and 
resumes execution. Note that Tl is blocked 
outside its critical section. Since Tl is not 
given the lock on SI but instead is sus¬ 
pended, the potential deadlock involving 
Tl and T2 is prevented. At time t^ T2 exits 
its critical section; it will return to its as¬ 
signed priority and immediately be 
preempted by task Tl. From this point on, 
Tl will execute to completion, and then T2 
will resume its execution until its comple¬ 
tion. 

Let B. be the longest duration of block¬ 
ing that can be experienced by task x.. The 
following theorem determines whether the 
deadlines of a set of periodic tasks can be 
met if the priority ceiling protocol is used: 

Theorem 4: A set of n periodic tasks 

using the priority ceiling protocol can 

be scheduled by the rate monotonic 

algorithm for all task phasings, if the 
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Figure 3. Task interactions for Example 6. 


following condition is satisfied^: 

£l Ql 

r,+ -+r„ 

. 

This theorem generalizes Theorem 1 by 
taking blocking into consideration. A 
similar extension can be given for Theo¬ 
rem 3. The B.'s in Theorem 4 can be used 
to account for any delay caused by re¬ 
source sharing. Note thatB^ is always zero, 
since the lowest priority task cannot, by 
definition, be blocked by a task of lower 
priority, and hence, is not included in 
the theorem’s formula. 

In the priority ceiling protocol, a task 
can be blocked even if it does not lock any 
semaphores. For example, in Figure 2, any 
task, X, with a priority between that of T1 
and T2 could be prevented from executing 
while T2 has semaphore S2 locked. This 
can happen because S2’s priority ceiling is 
greater than the priority of x. Therefore, if 
T1 tries to lock S1 while T2 has locked S2, 
T2 will inherit Tl’s priority and will pre¬ 
vent any tasks of intermediate priority 
from executing. Since the low priority task 
T2 prevents the execution of the intermedi¬ 
ate priority tasks, these tasks suffer prior¬ 
ity inversion, or blocking. This source of 
blocking is the cost of avoiding unbounded 
priority inversion. It must be taken into 
account when applying Theorem 4. 

An example application of the theory. 

A simple example illustrates how to apply 


the scheduling theory. 

Example 6: Consider the following task 
set (see Figure 3): 

(1) Emergency handling task: execu¬ 
tion time = 5 milliseconds; worst 
case interarrival time = 50 millisec¬ 
onds; deadline is 6 milliseconds 
after arrival. 

(2) Aperiodic event handling tasks: 
average execution time = 2 millisec¬ 
onds; average interarrival time = 40 
milliseconds; fast response time is 
desirable, but there are no hard dead¬ 
lines. 

(3) Periodic task Xj; worst-case execu¬ 
tion time = 20 milliseconds (which 
includes service time for accessing a 
shared data object and a shared 
communication server); period = 
100 milliseconds; deadline is at the 
end of each period. In addition, x, 
may block x, for 10 milliseconds by 
using a shared communication 
server, and task x^ may block x, for 
20 milliseconds by using a shared 
data object. 

(4) Periodic task x^: execution time = 40 
milliseconds (including 20 millisec¬ 
onds spent accessing the shared data 
object); period = 150 milliseconds; 
deadline is 20 milliseconds before 
the end of each period. 

(5) Periodic task X3: execution time = 
100 milliseconds (including 10 


milliseconds for accessing the com¬ 
munications server); period = 350 
milliseconds; deadline is at the end 
of each period. 

Solution: First, we create a sporadic 
server for the emergency task, with a pe¬ 
riod of 50 milliseconds and a service time 
of 5 milliseconds. Since the server has the 
shortest period, the rate monotonic algo¬ 
rithm will give this server the highest pri¬ 
ority. It follows that the emergency task 
can meet its deadline. 

Since the aperiodic event handling ac¬ 
tivities have no deadlines, they can be 
assigned a low priority. However, since 
fast response time is desirable, we create a 
sporadic server executing at the second 
highest priority. The size of the server is a 
design issue. A larger server (that is, a 
server with higher utilization) needs more 
processor cycles but will give better re¬ 
sponse time. In this example, we choose a 
large server with a period of 100 millisec¬ 
onds and a service time of 10 milliseconds. 
We now have two tasks with a period of 
100 milliseconds — the aperiodic event 
server and periodic task Xj. The rate mono¬ 
tonic algorithm allows us to break the tie 
arbitrarily, and we let the server have the 
higher priority. 

We now have to check if the three peri¬ 
odic tasks can meet their deadlines. Since, 
under the priority ceiling protocol, a task 
can be blocked at most once by lower 
priority tasks, the maximal blocking time 
for task x, is = maximum (10 millisec¬ 
onds, 20 milliseconds) = 20 milliseconds. 
Since X3 may lock the semaphore associ¬ 
ated with the communication server and 
the priority ceiling of is higher than that 
of task Xj, task x^ can be blocked by task X3 
for 10 milliseconds. (This may occur if x, 
blocks X, and inherits the priority of X,.) 
Finally, task Xj has to finish 20 millisec¬ 
onds earlier than the nominal deadline for 
a periodic task. This is equivalent to saying 
that Xj will always be blocked for an addi¬ 
tional 20 milliseconds, but its deadline is at 
the end of the period. Hence, B^ = (10 -I- 20) 
milliseconds = 30 milliseconds.* At this 
point, we can directly apply the appropri¬ 
ate theorems. However, we can also reduce 
the number of steps in the analysis by 
noting that period 50 and 100 are harmon¬ 
ics, so we can treat the emergency server 


* Note that the blocked-at-most-once result does not 
apply here. It only applies to blocking caused by task 
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mathematically as if it had a period of 100 
milliseconds and a service time of 10 milli¬ 
seconds. We now have three tasks with a 
period of 100 milliseconds and an execu¬ 
tion time of 20 milliseconds, 10 millisec¬ 
onds, and 10 milliseconds, respectively. 
For the purpose of analysis, these three 
tasks can be replaced by a single periodic 
task with a period of 100 milliseconds and 
an execution time of 40 milliseconds (20 + 
10 -I-10). We now have the following three 
equivalent periodic tasks for analysis: 

• Task T,: C, = 40 ; T, = 100 ; S, = 20 ; 

(/, = 0.4 

• Task y. = 40 ; = 150 ; = 30 ; 

(/, = 0.267 

• Task -Cj: C3 = 100 ■, T, = 350 ; 8^ = 0 ■ 

f/j = 0.286 

Note thatBj is zero, since a task can only be 
blocked by tasks of lower priority. Since 
is the lowest priority task, it can’t be 
blocked. 

When Theorem 3 is extended to account 
for blocking, we simply check to be sure 
that each task will meet its deadline if it is 
blocked for the maximal amount of time: 

(1) Task X,: Check C, B, < T,. If this 
inequality is satisfied, x, will always meet 
its deadline. Since 40 20 < 100, task x, is 
schedulable. 

(2) Task t^: Check each of the following: 

C, Cj + Bj < r, 

40-I-40 +30 > 100 

2C, + Cj + B^ < Tj 
80 + 40 + 30= 150 

These equations reflect the two schedul¬ 
ing points applicable to task x^, and take 
into account the fact that task x^ will be 
blocked at most B^ milliseconds. More¬ 
over, we don’t need to consider the block¬ 
ing time for task x^ because this time only 
affects the completion time for Xj; it cannot 
affect Xj’s completion time. Hence, task x^ 
is schedulable and in the worst-case phas¬ 
ing will meet its deadline exactly at time 
150. 

(3) Task x^: The analysis here is identical 
to the analysis for Task 3 of Example 2. 
Hence, task x^ is also schedulable and in 
the worst-case phasing will meet its dead¬ 
line exactly at time 300. It follows that all 
three periodic tasks can meet their dead¬ 
lines. 


Next, we determine the response time for 
the aperiodics. The server capacity is 10 
percent and the average aperiodic work¬ 
load is 5 percent (2/40). Because most of 
the aperiodic arrivals can find tickets, we 
would expect a good response time. In¬ 
deed, using a M/M/1 approximation'" for 
the lightly loaded server, the expected 
response time for the aperiodics is W = 
£[5]/(l - p) = 2/(1 - (0.05/0.10)) = 4 milli¬ 
seconds where £[5] is the average execu¬ 
tion time of aperiodic tasks and p is the 
average server utilization. Finally, al¬ 
though the worst-case total periodic and 
server workload is 95 percent, we can still 
do quite a bit of background processing, 
since the soft deadline aperiodics and the 
emergency task are unlikely to fully utilize 
the servers. 

The results derived for this example 
show how the scheduling theory puts real¬ 
time programming on an analytic engi¬ 
neering basis. 

Real-time scheduling 
in Ada 

Although Ada was intended for use in 
building real-time systems, its suitability 
for real-time programming has been 
widely questioned. Many of these ques¬ 
tions concern practical issues, such as fast 
rendezvous and interrupt handling. 

These problems are being addressed by 
compiler vendors aiming at the real-time 
market. More important are concerns about 
the suitability of Ada’s tasking model for 
dealing with real-time programming. For 
example, tasks in Ada run nondeterminis- 
tically, making it hard for traditional real¬ 
time programmers to decide whether any 
tasks will meet their deadlines. 

In addition, the scheduling rules of Ada 
don’t seem to support priority scheduling 
well. Prioritized tasks are queued in FIFO 
order rather than by priority; high priority 
tasks can be delayed Indefinitely when 
calling low priority tasks (due to priority 
inversion); and task priorities cannot be 
changed when application demands 
change at runtime. 

Fortunately, solutions exist within the 
current language framework, although 
some language changes would be helpful 
to ensure uniform implementation support. 

Whether or not language changes are 
made, we must be careful to use Ada con¬ 
structs in ways that are consistent with rate 
monotonic principles. The Real-Time 
Scheduling in Ada Project at the Carnegie 
Mellon University Software Engineering 


Institute is a cooperative effort between 
CMU, the SEI, system developers in indus¬ 
try, Ada vendors, and government agen¬ 
cies. It aims to specify coding guidelines 
and runtime system support needed to use 
rate monotonic scheduling theory in Ada 
programs. The guidelines are still evolving 
and being evaluated, but so far it seems 
likely they will meet the needs of a useful 
range of systems. 

The remainder of this section summa¬ 
rizes the approach being taken by the proj¬ 
ect and shows how Ada’s scheduling rules 
can be interpreted to support the require¬ 
ments of rate monotonic scheduling algo¬ 
rithms. 

Ada real-time design guidelines. Since 
Ada was not designed with rate monotonic 
scheduling algorithms in mind, it is not 
surprising to find some difficulties in using 
these algorithms. There are basically two 
ways of using rate monotonic algorithms 
in Ada: 

(1) follow coding guidelines that take 
into account the scheduling policy that 
must be supported by every real-time Ada 
implementation or 

(2) take advantage of the fact that Ada 
allows rate-monotonic scheduling algo¬ 
rithms to be supported directly by a spe¬ 
cial-purpose runtime system. 

There are several Ada usage issues that 
must be addressed: 

(1) how to code Ada tasks that must 
share data, 

(2) how to use sporadic server concepts 
for aperiodic tasks, and 

(3) how to ensure precise scheduling of 
periodic tasks. 

We discuss the first two issues in this 
article. For data sharing among periodic 
Ada tasks (client tasks), our first guideline 
is that these tasks must not call each other 
directly to exchange data. Instead, when¬ 
ever they must read or write shared data or 
send a message, they call a monitor task. 
Each monitor task has a simple structure — 
an endless loop containing a single select 
statement with no guards (see Figure 4). 
(The prohibition against guards simplifies 
the schedulability analysis and the runtime 
system implementation, but otherwise is 
not essential.) 

This structure models the notion of criti¬ 
cal regions guarded by a semaphore; each 
entry is a critical region for the task calling 
the entry. By using this coding style, we 
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tasks with critical regions guarded by a single semaphore. The corresponding 
monitor task acts as the semaphore guarding the critical regions. Each entry of 
the monitor task is the critical region for one of the periodic tasks. 


have a program structure that can be ana¬ 
lyzed directly in rate monotonic terms. 

Client tasks are assigned priorities ac¬ 
cording to the rate monotonic algorithm. 
There are two options when assigning a 
priority to a monitor. If the Ada runtime 
system supports the priority ceiling proto¬ 
col directly, then give the monitor task an 
undefined priority. In addition, tell the 
runtime system the priority ceiling of the 
monitor—that is, the highest priority of all 
its clients — using an implementation- 
defined pragma or system call. 

If the ceiling protocol is not supported 
directly, the same schedulability effect can 
be emulated by giving the monitor task a 
priority that is just higher than the priority 
of any client task. This artificial priority 
assignment is consistent with the priority 
ceiling protocol. 

To see this, note that once a high-prior¬ 
ity client task starts to execute, it cannot be 
blocked by any lower priority client that 
has called an entry of the monitor; if the 
low-priority client is in rendezvous with 
the monitor before the high-priority client 
is ready to execute, the low-priority client 
will complete its rendezvous before the 
higher priority client is allowed to execute. 
If the low-priority task is not in rendezvous 
with a monitor task and the high-priority 
client becomes eligible to run, the low- 
priority task will be preempted and won’t 
be allowed to execute until the high-prior¬ 
ity-client task has finished its work. 


Therefore, a high-priority client task can 
be blocked by at most one lower priority 
client task. The effect on system perfor¬ 
mance of giving the monitor task a high 
priority is simply that the worst-case 
blocking time is more frequently experi¬ 
enced; when rendezvous times are short, 
this effect is negligible. 

Giving monitor tasks a high priority is 
not an acceptable implementation of the 
ceiling protocol if the monitor task sus¬ 
pends itself while in rendezvous, for ex¬ 
ample, while waiting for an I/O device to 
complete. Suspension allows other tasks to 
execute, meaning first-in, first-out (that is, 
unprioritized) entry queues could build up 
or critical sections could be entered under 
conditions inconsistent with the require¬ 
ments of the priority ceiling protocol. If 
such a suspension is a possibility, the ceil¬ 
ing protocol should be supported directly 
in the Ada runtime implementation. 

We have shown how the effect of the 
priority ceiling protocol can be provided at 
the application code level. A simple ver¬ 
sion of the sporadic server algorithm can 
also be supported at the application code 
level by creating a server task with the 
following structure: 

task body Server is 

Tickets := Initial_Budget; 

- set initial execution time budget 
begin 
ioop 


accept Aperiodic_Request; 
Set_Replenishment_Time; 

— do work 

Decrement_Ticket_Count; 

- one ticket per request 
if No_More_Tickets then 

Delay_Until_Replenishment_Time; 

Replenish_Tickets; 
end if; 
end ioop; 

end Server; 

In essence, this task refuses to accept 
work unless it has a ticket to complete a 
request. The algorithm for deciding when 
to replenish tickets can be considerably 
more complicated, and a single server can 
be structured to accept a variety of service 
requests with different execution times. 

If the runtime system supports the spo¬ 
radic server algorithm directly, then the 
budget and replenishment period are speci¬ 
fied by system calls or by implementation- 
dependent pragmas, and the loop simply 
accepts an entry call and does the work. 
Execution time management and task sus¬ 
pension is then handled directly by the 
runtime. 

On Ada scheduling rules. The most 
general solution to the problem of using 
rate monotonic scheduling algorithms in 
Ada, within the constraints of the lan¬ 
guage, is simply to not use pragma 
PRIORITY at all. 

If all tasks in a program have no 
assigned priority, then the runtime system 
is free to use any convenient algorithm 
for deciding which eligible task to run. 
An implementation-dependent pragma 
could then be used to give 
“Rate_Monotonic_Priorities” to tasks. 

This approach would even allow “pri¬ 
orities” to be changed dynamically at run¬ 
time because, in a legalistic sense, there 
are no Ada priorities at all. The only prob¬ 
lem with this approach is Ada’s require¬ 
ment that calls be queued in order of arri¬ 
val, independent of priority. 

However, even this problem can be 
solved efficiently. To get the effect of 
prioritized queueing, the runtime sched¬ 
uler should ensure that no calls “arrive” 
until they can be accepted. This can be 
achieved by a legalistic trick — keeping 
the Count attribute zero (because logi¬ 
cally, no entry calls are queued), and corre¬ 
spondingly suspending tasks making entry 
calls at the point of the call if the priority 
ceiling protocol requires that the call be 
blocked. 

The elimination of entry queues also 
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makes the runtime more efficient. How¬ 
ever, we must emphasize here that this 
treatment of entry calls is only allowed if 
no tasks have a priority specified by Ada’s 
pragma PRIORITY. 

Of course, telling programmers to as¬ 
sign “Rate_Monotonic_Priorities” to tasks 
but not to use pragma PRIORITY surely 
says we are fighting the language rather 
than taking advantage of it. But, the impor¬ 
tant point is that no official revisions to the 
language are needed. 

Now, let us consider in more detail the 
specific Ada scheduling rules that cause 
difficulties and the appropriate ways of 
getting around the problems. When we 
describe these workarounds, we don’t in¬ 
tend to suggest that Ada is therefore com¬ 
pletely satisfactory for use with rate mono¬ 
tonic theory, but rather, to show that soft¬ 
ware designers need not wait for a revision 
to the Ada standard before trying out these 
ideas. 

• CPU allocation: Priorities must be ob¬ 
served. Ada requires that, in a uniproces¬ 
sor environment, the highest priority task 
eligible to run be given the CPU. For appli¬ 
cations using the rate monotonic theory, 
this scheduling rule is correct as far as it 
goes. The only problem arises when deter¬ 
mining the priority at which a task rendez¬ 
vous should be executed. This is discussed 
below. 

• Hardware task priority: Always 
higher than software task priorities. This 
Ada rule reflects current hardware designs, 
but hardware interrupts should not always 
have the highest priority from the view¬ 
point of the rate monotonic theory. 

Solution: When handling an interrupt 
that, according to the rate monotonic the¬ 
ory, should have a lower priority than the 
priority of some application task, keep the 
interrupt handling actions short (which is 
already a common practice) and include 
the interrupt handling duration as blocking 
time in the rate monotonic analysis. In 
other words, use the scheduling theory to 
take into account the effect of this source 
of priority inversion. 

• Priority rules for task rendezvous. The 
priority of a task can only be increased 
while executing a rendezvous, and any 
increase is based only on the priorities of 
the rendezvousing tasks. In particular, the 
priority is not increased based on the prior¬ 
ity of blocked tasks, as required by the 
priority ceiling protocol. 

Solution: We have already discussed the 


two solutions to this problem: (1) give 
monitor tasks a high priority, or (2) imple¬ 
ment the priority ceiling protocol directly 
in the runtime system. If a monitor task is 
given a priority higher than that of its 
callers, then no increase in priority is ever 
necessary, so the problem is side-stepped. 
Alternatively, give the monitor task no 
priority at all. An implementation can then 
use priority ceiling rules to increase the 
priority of the called task to the necessary 
level since, in this case, the Ada rules say 
a rendezvous is executed with “at least” the 
priority of the caller, that is, the rendez¬ 
vous can be executed at the priority of a 
blocked task. 

• FIFO entry queues. Ada requires that 
the priority of calling tasks be ignored; 
calls must be serviced in their order of 
arrival, not in order of priority. Using FIFO 
queues rather than prioritized queues usu¬ 
ally has a serious negative effect on real¬ 
time schedulability. FIFO queues must be 
avoided. 

Solution: As noted earlier, it is possible 
to avoid FIFO queueing by giving monitor 
tasks a high priority or by using an imple¬ 
mentation-defined scheduler to ensure that 
calls do not arrive unless they can be ac¬ 
cepted. In either case, no queues are 
formed. 

• Task priorities: Fixed. This rule is 
inappropriate when task priorities need to 
be changed at runtime. For example, when 
a new mode is initiated, the frequency of a 
task and/or its criticality may change, 
implying its priority may change. In addi¬ 
tion, the scheduling rules for a certain class 
of aperiodic servers demand that the prior¬ 
ity of such a server be lowered when it is 
about to exceed the maximum execution 
time allowed for a certain interval of time 
and be raised when its service capacity has 
been restored. 

Solution: When an application needs to 
adjust the priority of a task at runtime, this 
task should be declared as having no Ada 
priority. The runtime system can then be 
given a way of scheduling the task appro¬ 
priately by, in effect, changing its priority. 

• Selective wait. Priority can be ignored. 
That is, the scheduler is allowed, but not 
required, to take priorities into account 
when tasks of different priorities are wait¬ 
ing at open select alternatives. 

Solution: If a monitor task is given a 
priority higher than that of any of its callers 
and is not suspended during a rendezvous 
(for example, by executing a delay state¬ 


ment), this rule doesn’t matter because 
there will never be more than one caller at 
any given time. Otherwise, the implemen¬ 
tation should select the highest priority 
waiting task. 

Summing up. From what our project has 
learned so far, it seems to be possible in 
practice to support analytic scheduling 
algorithms in Ada by using an enlightened 
interpretation of Ada’s scheduling rules 
together with a combination of runtime 
system modifications and appropriate 
coding guidelines. Of course, it would be 
better if the language did not get in the way 
of rate monotonic scheduling principles. 
The future revision of Ada should reword 
some of these rules so that support for rate 
monotonic scheduling is more clearly al¬ 
lowed. 


I n this article, we have reviewed some 
important results of rate monotonic 
scheduling theory. The theory allows 
programmers to reason with confidence 
about timing correctness at the tasking 
level of abstraction. As long as analytic 
scheduling algorithms are supported by 
the runtime system and resource utiliza¬ 
tion bounds on CPU, I/O drivers, and com¬ 
munication media are observed, the timing 
constraints will be satisfied. Even if there 
is a transient overload, the tasks missing 
deadlines will be in a predefined order. 

Rate monotonic scheduling theory puts 
real-time system design on a firmer, ana¬ 
lytical, engineering basis than has been 
possible before now. Moreover, the theory 
is not just an academic curiosity. It has 
been used in the design of several produc¬ 
tion systems. Interestingly, none of the 
systems actually supported the theory in an 
ideal way. 

The theory has proven to be quite robust 
in giving insight into the behavior of exist¬ 
ing systems that are failing to meet their 
performance requirements and to suggest 
remedies. It promises to be even more 
useful when used at the outset in designing 
real-time systems. 

The ideas have been applied to uni¬ 
processor systems and to a real-time local 
area network. Currently, work is actively 
underway to apply the ideas to distributed 
systems in a more integrated fashion. 

Although the treatment of priorities by 
the current Ada tasking model can and 
should be improved, the scheduling algo¬ 
rithms can be used today within the exist¬ 
ing Ada rules if an appropriate coding and 
design approach is taken and if runtime 
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systems are written to take full advantage 
of certain coding styles and the existing 
flexibility in the scheduling rules. DDC-I, 
Verdix, Telesoft, and Ready Systems are 
among the Ada compiler vendors working 
on supporting rate monotonic algorithms. 
In particular, DDC-I and Verdix currently 
support the priority inheritance protocol,^ 
whose performance for practical purposes 
is quite similar to that of the priority ceiling 
protocol. Verdix also provides special 
optimizations for monitor tasks. The SEI is 
providing technical reports showing how 
to implement the algorithms, and we will 
be providing test programs to check the 
correctness and the performance of the 
implementations. ■ 
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I ntroduced about 20 years ago, bar 
codes have spread from supermarkets 
to department stores, the factory 
floor, the military, the health industry, the 
insurance industry, and more. The barcode 
industry uses the term symbology to denote 
each particular bar code scheme, while the 
term symbol refers to the bar code label 
itself. The last few years have seen the in¬ 
troduction of many new symbologies, and 
an ongoing debate compares them with 
each other and with schemes for encoding 
printed information on a substrate. There¬ 
fore, we need to look into information and 
coding theory to make meaningful com¬ 
parisons. 

Early codes, in particular UPC (Univer¬ 
sal Product Code), resulted from careful 
studies,' but such studies faced the techno¬ 
logical constraints of 20 years ago and 
responded to the expected applications of 
that time. A more recent study^ focused 
only on some aspects of the encoding. The 
continuing drop in the price of computing 
hardware makes feasible in the near future 
the use of powerful processors that would 
have been deemed prohibitively expensive 
to use in the past. Thus, we can justify 
examining encoding and decoding 
schemes that looked impractical 20 years 
ago. 

Recent years have also seen demands to 
increase the density of information pack¬ 
ing to create a “portable data file” as op¬ 
posed to the “license plate file” of conven¬ 
tional bar code symbols. You can see the 
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L 1 

To compare encoding 
and decoding schemes 
requires us to first look 
into information and 
coding theory. This 
article discusses 
problems and possible 
solutions in encoding 
information. 


distinction between the two forms in the 
following example; The bar code of a 
supermarket item consists of 11 digits, 
which represent an identifying number but 
not a description of the product. For ex¬ 
ample, the price look-up must be accessed 
in a database keyed to the number in the bar 
code. An alternative would be to use a 
much longer bar code (or other encoding) 
to store all the relevant information, such 
as price, name of the product, manufac¬ 
turer, weight, inventory data, expiration 


* Pavlidis is with the Department of Computer Science, 
State University of New York at Stony Brook, and 
serves as a scientific advisor to Symbol Technologies. 
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date, etc. That would constitute a “portable 
data file,” because the information could 
be retrieved without access to a database. 
While a price look-up file (PLU) is neces¬ 
sary and convenient in a retail environ¬ 
ment, this may not be the case at a distribu¬ 
tion center receiving from and shipping to 
remote warehouses or overseas depots. 

The basic problem we face is that of 
encoding information on some medium 
using printing technology. Any such en¬ 
coding has the following conflicting re¬ 
quirements: 

• We want the code to have a high den¬ 
sity of information. 

• We want to be able to read the code 
reliably. 

• We want to minimize the cost of the 
printing process. 

• We want to minimize the cost of the 
reading equipment. 

It is essential to look at all the factors to 
reach practical and meaningful conclu¬ 
sions. Bar codes have been criticized often 
for having a low density of coded informa¬ 
tion, but some of their “inefficiencies” 
were introduced deliberately to facilitate 
their robust reading by a wide variety of 
means. 

An important distinction exists between 
the method of “painting” bits on paper 
^channel encoding) and that of encoding 
information into bits (source encoding). 
The distinction is well understood in cod- 
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ing theory: the electronics of representing 
a zero or a one are dealt with separately 
from how English text, for example, is 
encoded into bits. The distinction is often 
overlooked in the discussion of bar codes 
because most of the early codes were de¬ 
fined as mappings between alphanumeric 
characters and “painted” paper. 

In this article we review the overall prin¬ 
ciples of bar coding and discuss in detail 
two bar codes in wide use, UPC and Code 
39, plus briefly outline some other bar 
codes and alternatives to bar coding. We 
touch on the information content of bar 
codes and deal with the noise and distor¬ 
tions that affect the reading of bar codes. 
Then we outline the process for bar code 
design using coding theory and introduce a 
distance between bar codes to allow the 
use of error detection and error correction 
techniques. Finally, we present design 
tables and a specific example showing how 
to increase the information density en¬ 
coded in bar codes by using error detection 
and error correction. 

The state of the art 

Bar codes encode information along one 
dimension with intervals of alternating 
diffuse reflectivity, usually black and 
white color. The intervals are actually 
stored as rectangles whose vertical height 
carries no information but facilitates the 
scanning process. The term bars denotes 
the rectangles with the foreground color 
while the term spaces denotes the intervals 
with the background color between the 
bars. The bars have the darker color, and 
special care is taken to ensure that. 

You might think this doesn’t work on 
soda cans, where the bars have a metallic 
color that reflects more light than the back¬ 
ground. However, the reflection from the 
bars is specular and directed away from the 
sensor. The spaces have a dull color with 
diffuse reflection, part of which is always 
captured by the sensor. Similarly, on trans¬ 
parent bottles the bars are not colored, so 
light goes through them rather than reflect¬ 
ing to the sensor. 

There are two fundamental ways of 
encoding information in such a one-di¬ 
mensional medium. In one we subdivide 
the available interval into modules and 
assign I’s and O’s to each module. Mod¬ 
ules with 1 ’s are painted and form the bars, 
while modules with O’s correspond to 
spaces. Obviously, a single bar or space 
may contain many modules. Such schemes 
are called delta codes in communication 
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Figure 1. Encoding of the binary string 100111000 by a delta code (top) and 
width code (bottom). 


theory. A more descriptive name would 
have been color codes, but we prefer the 
standard term to limit the introduction of 
new terminology. 

In another scheme we assign each bit to 
a bar or space and make that element wide 
if the bit is one and narrow if the bit is 0. We 
refer to such schemes as width codes, al¬ 
though the common name used in the bar¬ 
coding industry is binary codes, because 
only two widths are used. We prefer the 
term “width code” because it describes 
more accurately the method used and be¬ 
cause the word binary has too broad a 
meaning in computer literature. 

Figure 1 shows two encodings of the 
binary string 100111000. In both cases the 
minimum printed width is the same. The 
delta code requires nine such widths (the 
number of bits), while the width code re¬ 
quires 13 such widths if a wide element is 
twice as wide as a narrow element. 

It was recognized from the beginning 
that, for bar codes to gain wide acceptance, 
they should be allowed to be printed in 
different sizes and read at a range of non¬ 
constant distances (for example, by hand¬ 
held laser scanners) and by devices with 
variable scanning speed. (The speed is 
extremely and unpredictably variable in 
hand-held wands. However, even laser 
scanners exhibit some variation in speed.) 
These requirements impose the constraint 


that such printed codes be self-clocking, 
which means that both the number of 
modules and the number of bars and spaces 
per code word must be fixed. Thus, delta 
codes (which inherently have a fixed 
number of modules) are required to have a 
fixed number of bars and spaces. A code 
with n modules and k pairs of bars and 
spaces is called an {n,k) code. Width codes 
are required to have not only a fixed num¬ 
ber of bars and spaces but also a fixed 
number of wide elements to achieve a fixed 
width. Among the most popular bar codes, 
the UPC is a (7,2) delta code (seven mod¬ 
ules, two bars and two spaces), while Code 
39 is a width code with nine elements (five 
bars and four spaces), three of which are 
wide. 

The self-clocking constraint for bar 
codes is more stringent than that for optical 
and magnetic recording,which share 
many of the features of bar codes. In such 
systems information is encoded under the 
run-length-limited (RLE) constraint. This 
constraint is specified by a pair of con¬ 
stants {d,k) where 0<d<k, which means 
two consecutive I’s are separated by at 
least d, but no more than k, O’s. The 
constant d is used to control the intersym¬ 
bol interference effects. The constant k is 
used to provide self-clocking through a 
phase-locked loop (PLL) with window¬ 
ing.’ This weaker constraint is possible 
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Figure 2. Derivation of the UPC code words. The seven modules (top line) have 
six boundaries (second line). A partition of the modules into two bars and two 
spaces requires three internal boundaries that can be placed in each of six 
locations. 


because optical and magnetic recording 
systems are closed systems where the dis¬ 
tance between the scanner and the symbol 
as well as the size of the symbol are fixed 
and known. Neither is known for bar codes, 
which are classified as open systems. 

Besides self-clocking we need some 
means to detect the direction of the scan. 
Practical requirements may demand that 
bar codes be scanned in either direction. 
(Many scanning devices, including those 
used in retailing, have repetitive scans in 
alternating directions.) There are two types 
of solutions to this problem. One is to have 
a unique start/stop code word on each 
symbol. The other is to use only one of two 
code words if they are mirror images of 
each other. For example, three modules of 
a delta code with only one bar and one 
space yield the combinations 

The last two are the mirror images of the 
first two and therefore cannot be distin¬ 
guished if you do not know the scanning 
direction. This results in taking only half of 
all possible code words. UPC uses only 
code words whose mirror image is not in 
the code, while Code 39 uses a unique 
start/stop code word. We next review both 
of these codes in detail. 


Some bar code types 

Universal Product Code. UPC is the 
symbology used in American supermar¬ 
kets for more than 15 years. What we 
describe here is version A, where each 
symbol encodes 12 digits. However, all 
versions use the same basic structure for 
the code words. Each UPC code word 
consists of two bars and two spaces with a 
total width of seven modules. The number 
of possible code words can be computed as 
follows: Two bars and two spaces require 
three dividers in one of six positions (be¬ 
tween modules) as shown in Figure 2. 
Therefore, the total number of partitions 
will be the same as the number of ways to 
choose three objects out of six, or 20. You 
can then construct 40 code words, depend¬ 
ing on whether the first element is a bar or 
a space. However, you cannot include code 
words that are mirror images of each other 
because of the need for bidirectional scan¬ 
ning. This leaves you with 20 possible 
code words. 

While symbols must be readable by 
scanning in either direction, we also want 
to detect the direction of scanning after¬ 
wards. UPC achieves that by assigning two 
code words for each digit: those used on 
the right part of the symbol start with a bar 
and those used on the left part start with a 


space. The two versions can be distin¬ 
guished because the ones starting with a 
bar have an even number of bar modules 
(even parity) and those starting with a 
space have an odd number of bar modules 
(odd parity). Table 1 shows this arrange¬ 
ment. (We will explain the last two col¬ 
umns of the table later.) You can see that 
each digit is assigned a single width com¬ 
bination. For example, 0 is 3,2,1,1. UPC 
specifies a symbol format as shown in 
Figure 3. 

The symbol contains the following 
groups of code words: 

• a left guard pattern 101 

• six digits of odd parity: 

— one digit denoting the industry type 
(such as 0 for grocery, 3 for pharma¬ 
ceutical, etc.) 

— five digits with the manufacturer’s 
code 

• a center guard pattern 01010 of five 
modules 

• six digits of even parity: 

— five digits with the item code 

— one check digit 

• a right guard pattern 101 

Laser scanners in the supermarkets use 
essentially orthogonal patterns. The height 
of each half of the symbol is expected to 
exceed its width so that one of the two 
beams is guaranteed to scan a symbol half. 
(It is a property of a block with height 
greater than width that an x pattern is guar¬ 
anteed to read it by at least one line of the 
X in any orientation of the symbol.) The 
symbol can be assembled afterwards be¬ 
cause each part is identified by the parity 
pattern. UPC allows “scanning by halfs” 
because the left and the right parts of the 
code are inherently identifiable from the 
local properties of each code word. 

One major source of distortions of bar 
codes is uniform ink spread (see the sec¬ 
tion “Noise and distortions” for more on 
this topic), which generally causes bars to 
be comparatively wider than spaces. For 
this reason bar code readers measure not 
the width of each bar or space but the edge- 
to-edge difference of successive bars. 
Figure 4 shows that the sum of the widths 
of a bar/space pair is not affected by ink 
spread. 

The last column of Table 1 shows the 
pair of edge-to-edge distances (called the 
/-distances) for each UPC code word. The 
pair characterizes the character uniquely 
except for the pairs 1 and 7 and 2 and 8. For 
those, an additional calculation must be 
performed, typically a comparison of the 


76 


COMPUTER 






















element widths themselves. For example. Table 1. Specification of Universal Product Code. 


if the second element is wider than the 
third, we decide in favor of an even 8 rather 
than an even 2. Of course, for an 8 the 
second element is twice as long as the 
third, while the opposite holds true for a 2. 


Left 

(odd) 

Right 

(even) 

Width 

Pattern 

/-Distances 
(odd) (even) 

0 

0001101 

1110010 

3,2,1,1 

4,3 

5,3 

Because of the ink spread and the preclas¬ 

1 

0011001 

1100110 

2 ,2,2,1 

3,4 

4,4 

sification provided by the r-distances, we 

2 

0010011 

1101100 

2 ,1,2,2 

4,3 

3,3 

use a more liberal rule. 

3 

0111101 

1000010 

1,4,1,1 

2,5 

5,5 


4 

0100011 

1011100 

1,1,3,2 

3,4 

2,4 

Code 39 (three of nine). Code 39 is a 

5 

0110001 

1001110 

1,2,3,1 

4,5 

3,5 

width code with three wide elements out of 

6 

0101111 

1010000 

1,1,1,4 

5,2 

2,2 

a total of nine: five bars and four spaces 

7 

0111011 

1000100 

1,3,1,2 

3,4 

4,4 

between them. It has been the standard for 

8 

0110111 

1001000 

1,2,1,3 

4,3 

3,3 

the Department of Defense since 1980. 
The total number of code words that it can 

9 

0001011 

1110100 

3,1,1,2 

3,2 

4,2 


generate is the number of ways three items 
can be chosen out of nine, or 84. It has code 
words for the 10 digits, the 26 letters, and 
eight special symbols (hyphen, period, 
space, asterisk (*), $, /, +, and %) so that a 
total of only 44 code words are used. The 
asterisk is used only as the first and last 
code word of a symbol. 

Table 2 shows some of the codes. A 1 
means a wide element and a 0 means a 
narrow element. If an edge shift (the most 
common reading error) occurs, it will 
change both the bar and the space patterns. 
For example, 10001,0100 might become 
11001,0000. The latter does not corre¬ 
spond to any Code 39 pattern. 

The patterns for both the bars and the 
spaces have been chosen in such a way that 
changing a single bit in either of them 
results in an illegal code word. Spaces have 
only an odd number of wide elements and 
bars only an even number. This allows the 
immediate detection of single errors. The 
code is called self-checking for that reason. 
The number of bar patterns with two wide 
elements is 10 (the number of ways to 
choose two out of five), and there are four 
space patterns with one wide element. This 
yields 40 code words. Four additional code 
words are obtained by using the four pat¬ 
terns with three wide spaces and only nar¬ 
row bars. 

In contrast to UPC, Code 39 has no 
specifications for the arrangement of code 
words on the symbol except that the aster¬ 
isk must be the first and last character and 
can appear only there. Called the special 
start-and-stop character, the asterisk 
makes it possible to determine the direc¬ 
tion of scanning. (Of course. Code 39 and 
all other codes have printing specifications 
for the spacing of code words on a symbol.) 

As Table 2 shows. Code 39 contains 
code words that are mirror images of each 
other, such as the pairs (P,*) and (K,U). 
Therefore, the direction cannot be decided 


Industry 

'e^ignator (0) Check digit (5) 

Center guard bar \ Right guard bt 



1 2 3 4 5 


6 7 8 9 0 


Figure 3. Illustration of the specifications of the UPC symbol. The readable 
characters are normally printed in OCR-B font. The diagram is not drawn to 
scale. 



Table 2. Part of the specification of 
Code 39. 


Figure 4. Illustration of the invariance 
of the edge-to-edge distance under ink 
spread. 
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Table 3. Information content of some real codes. 


Code Name 

Closest 

Theoretical Model 

Number of 
Symbols Used 

Total Width 
(in modules) 

H 

UPC 

delta(7,2) 

10 

7 

0.474 

Code 128 

delta(ll,3) 

106 

11 

0.617 

Code 93 

delta(9,3) 

48 

9 

0.621 

Code 39 

width(9,3) 

44 

13.5* 

0.404 

Codabar 

width(7,2) 

16 

10* 

0.400 


* Assuming a 2.5:1 wide over narrow ratio. 


locally but must be determined from the 
start-and-stop code word. If the first code 
word is decoded as P, then we conclude 
that we are looking at the last code word of 
a symbol. The major practical implication 
of this design is that Code 39 does not 
allow local detection of the scan direction 
and cannot be decoded, even partially, 
without at least one of the start-and-stop 
code words. 

Other bar codes. While UPC and Code 
39 are two of the most widely used codes, 
quite a few others have been implemented. 
One of the earliest bar codes (circa 1968) is 
Code 2 of 5, which is a width code using 
only one of the colors with the other serv¬ 
ing only as a delimiter. It has been used for 
airline baggage and cargo handling, among 
other applications. Interleaved Code 2 of 5 
is similar, using both colors with each 
denoting a separate character. 

Another width code, Codabar, consists 
of four bars and three spaces. One of the 
bars and one of the spaces is wide, yielding 
a total of 12 code words. Four additional 
code words are obtained by using three 
wide bars, and four more code words using 
one wide bar and two wide spaces. Co¬ 
dabar has been used by libraries and at 
blood banks. 

Besides UPC, (n,k) codes in wide use 
include the following: 

• Code 93, introduced in 1982, has nine 
modules and three pairs of bars and spaces, 
plus a 47-character set and a stop code 
word. The basic set encodes the 10 digits, 
26 uppercase characters, seven punctua¬ 
tion marks, and four shift code words to 
extend the meaning of the other characters. 

• Code 128, introduced in 1981, has 11 
modules and three pairs of bars and spaces. 
This code has 105 distinct characters plus 
a stop code word. It is probably the first 


code with a clear distinction between chan¬ 
nel encoding and source encoding. Three 
of the code words are used at the start of the 
symbol to denote one of three types of 
source encoding. Two of the types involve 
a mixture of alphanumerics, while the third 
encodes the numbers between 0 and 105. 

A recent development in bar coding is 
the introduction of stacked bar codes, also 
called two-dimensional codes. Such 
schemes use a one-dimensional code in a 
series of rows as the basic encoder. Code 
49, introduced in 1987, is based on a new 
(n,k) code with 16 modules and four pairs 
of bars and spaces. Code 16K was intro¬ 
duced in 1988 based on an extension of 
Code 128. Identcode and PDF417 were 
introduced in 1989. The former is based on 
Code 39 and the latter on a new in,k) code 
with 17 modules and four pairs of bars and 
spaces. Such stacked bar codes present a 
significant advance and additional chal¬ 
lenges. (Because of space limitations, we 
will discuss these in a future article.) 

For more details on bar code specifica¬ 
tions and for a complete review of all the 
existing symbologies, refer to the bar¬ 
coding literature.*"’ 

Information content of 
bar codes 

If a code has n modules and can generate 
S{n) code words, then we define its infor¬ 
mation content, per module, as 

H(n) = hog^Sin) (D 

If we need a width W to print the n modules 
on the substrate, then we define the density 
of the code (in bits per unit length) as 

D(n) = ^log25(n)=^//(n) (2) 


where X denotes the module width. An un¬ 
restricted delta code can encode up to 2" 
code words so that its information density 
is 

OaC”) = ~ ^ ~ X 

In a width code, with the ratio of wide to 
narrow equal to two, the number of effec¬ 
tive modules will be n-j, if j is the number 
of bits set to 1. Then the number of possible 
code words is 

rn-/n 

5„,(n)=l[Y] (4) 

y=o J 

This is equal to the nth Fibonacci number, 
which is given by 

This equation is a special case of a well- 
known result by Shannon in 1948. The first 
fraction in Equation 5 equals 1.618 and the 
second equals -0.618, so that as n increases 
the second term goes to zero. For values of 
n greater than 5, the following provides a 
very good approximation: 

S„,(n) = 0.4472 •(!.618r' (6) 


Therefore, the density of an unrestricted 
width code is 

^ log2SK>(n) = log21.618 


log2(1.618 -0.4472) 
W 


DM 


0.694 0.467 
’ X W 


(7) 


Thus, width codes have a density of ap¬ 
proximately 70 percent that of delta codes 
with the same module width. 

The above densities are theoretical 
maxima. The need for self-clocking, re¬ 
dundancy for error detection, and other 
factors make it necessary to use lower 
densities. Table 3 lists the information 
content and some important parameters for 
some of the existing codes. We need to 
look separately at each factor that affects 
the information content. We start with the 
effects of self-clocking and proceed with 
the calculation of the capacity of {n,k) delta 
codes and the capacity of (wi.vv) width 
codes. The latter symbol denotes a code of 
m elements, w of them wide. 


(n,k) codes. The maximum number of 
distinct code words of an (n,k) code is well 
known': 
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S{n.k)-[2k\] = 


{n~\){n-2)...{n-2k+\) 

(2/t-l)(2*-2)...3-2 


( 8 ) 


This is the number of combinations of 2k- 
1 out of n-\ objects. Derive the result by 
observing that there are n-1 module 
boundaries and 2^-1 bar/space boundaries 
(also see the section “Universal Product 
Code”). These combinations represent 
only the number of distinct zones, and we 
should expect twice as many code words 
because each zone pattern can be given one 
of two color arrangements. On the other 
hand, we cannot use half of the zone pat¬ 
terns, because of the need for bidirectional 
scanning. For each width pattern we must 
reject the one obtained by reversing the 
width sequence. These two factors cancel 
each other, and we are left with the number 
given by Equation 8. 

UPC is a (7,2) code, therefore it has 20 
possible code words (as we have already 
seen in that section above). Since the 
number of modules is n, the information 
content is 


//(«,*) = ilog2 [ 2 ^ 1 ^] [log2(«-0 

- l0g2(l)] = i I log2( J - 1 ) 

For a given «, S is maximum when 2k-\ is 
exactly half of n-1, which implies n-1 = 
2(2k-\) or 

n = 4*-l (10) 


Codes where n and k satisfy the above 
equation are called symmetric codes. 
Table 4 lists the values of S and H for 
various (ji,k) codes. 

We observe from Table 4 that a (7,2) 
code has H equal to 0.617, while from 
Table 3 we see that UPC has H equal to 
0.474. The difference, 0.143, is the loss 
because of the need for error detection. 

It is possible to derive an approximate 
but concise expression for S(n,k) using 
Stirling’s formula," which approximates 
n!. For symmetric {n,k) codes (that is, a 
{Ak-\,k) code) Equation 8 yields 



Equation 11 shows the “loss” factor of 
(n,k) codes compared to the theoretical 
maximum of 2" for delta codes. The loss 
factor is 


Table 4. Characteristics of some {n,k) codes. 


k 

in.k) 

S 

H 

Name of Related Code** 

2* 

7,2 

20 

0.617 

UPC 


3 

9,3 

56 

0.645 

Code 93 


3* 

11,3 

252 

0.725 

Code 128 


4 

14,4 

1,716 

0.767 



4* 

15,4 

3,432 

0.783 



4 

16,4 

6,435 

0.791 

Code 49 


4 

17,4 

11,440 

0.793 

PDF417 


5* 

19,5 

48,620 

0.819 



* Symmetric codes. 

** Recall that the actual codes do not 

use all possible code words. 


Table 5. 

Statistics for some (n,k,m) codes. 



n,k 

m 

L 


S-L 

Efficiency 

11,3 

5 

6 


246 

99.56% 


4 

6+30=36 


216 

97.21% 


3 

36+90=126 

126 

87.46% 

16,4 

8 

8 


6,427 

99.98% 


7 

8+56=64 


6,371 

99.88%) 


6 

64+224=288 

6,147 

99.47% 


5 

288+672= 

=960 

5,475 

98.15% 


Taking the binary logarithm of S and divid¬ 
ing by n we find that 

is*" 

This yields 0.626 for the (7,2) code and 
0.7285 for the (11,3) code, which are quite 
close to the correct values 0.617 and 
0.7252. Most important, it shows the effect 
of increasing n. As n -» 00, H{n) -> 1, the 
maximum theoretical information content. 
The equation for the density is 


1 _ log2[27t(n-l)] 
'X 2W 


(13) 


where W is the width of a code word. 


(n,k,m) codes. (n,k) codes with large n 
contain some bars or spaces of width equal 
to n-2k+ 1, which ranges from 4 for a (7,2) 
code to 11 for a (19,5) code. Very wide 
intervals are detrimental for the reading 
process because they can be confused with 
margins or other demarcations. Therefore, 
some symbologies omit the combinations 
containing very wide intervals. We will 


show that this eliminates relatively few 
codes. 

Let« be a particular (integer) width. If u 
is greater than nl2-k+\, then the code can 
have at most one instance of u. For ex¬ 
ample, a (16,4) code can have at most one 
width equal to 6, but two widths equal to 5. 
We can easily calculate the number of code 
words containing an element of such 
width. The particular width can occur in 
any of 2k places. This leaves n-u modules 
to be distributed into 2k-\ places. There 
are 

V2k-2^ ( 14 ) 


such possibilities. Therefore, if m is greater 
than or equal to n/2 -k + 1, the number of 
“lost” code words is 



We use the notation (n,k,m) to denote a 
code that has all the code words of an (n,k) 
code except those with width higher than 
m. Table 5 lists L for a set of codes. The 
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Table 6. Information content of width (binary) codes with m elements, w of them 
wide. 


(m.w) 

S 

H 

D 

Name of Related Code 

5,2 

10 

0.415* 

1 

Interleaved 2 of 5 

7,2 

21 

0.439 

1 

Codabar** 

9,3 

84 

0.474 

1 

Code 39 


* Counting both space- and bar-encoded code words. 

** Actually, Codabar consists of two codes: (4,1) and (3,1) for a total of 12 code words 
plus four special code words obtained from a (4,3) code and another four from a (4,2) 
code. 


efficiency is computed as 

log2(^-^) 

logzS 

the ratio of remaining bits over the bits for 
(n,k). 

The small drop in information content 
suggests that codes with large n increase 
the information content without increasing 
the difficulty of decoding. Such codes may 
be represented by the longest element 
expressed in module units. Code (16,4,6) 
is a code with maximum element length 5. 
Code (11,3) has the same maximum ele¬ 
ment length, but its information content is 
only 0.725, which is less than that for code 
(16,4,6). Note that Code 49 uses a (16,4,6) 
code as its basis (with efficiency of 99.47 
percent) and that Code 128 is really an 
(11,3,4) code with efficiency of 97.21 
percent. 


(m,w) width codes. The capacity of 
(m,w) width codes equals the number ob¬ 
tained by selecting w objects out of m or 


5».(m,w) = [^] = 


m(m-l)...(m-w+l) 

w(vi^l)...3-2 


(16) 


Their length equals m+wr where r is the 
ratio of wide over narrow minus one. 
Therefore, the information content is given 
by 

Table 6 lists the capacity of some (m,w) 
codes assuming the width of wide ele¬ 
ments is 2.5 times the width of narrow 
elements. We see that the information 
capacity of a (9,3) width code is 0.474, 
while the capacity of Code 39 (see Table 3) 
is 0.404. The difference, 0.070, is due to 
the error detection feature of the code. 


Alternatives to bar 
codes 

A natural question is whether anyone 
could have come up with a better way to 
label items than bar codes. We can abstract 
the problem and state it as follows: 

• Given a line segment, devise a scheme 
of subdivision into subsegments hav¬ 
ing one of two colors so that the re¬ 
corded information is maximized sub¬ 
ject to constraints on the probability of 
undetectable reading errors. 

The restriction to two colors is an impor¬ 
tant industrial constraint, and any depar¬ 
ture from it will involve significant finan¬ 
cial commitments by the industry. If we 
ignore the constraint of self-clocking, then 
we have a simple theoretical solution. Let 
L be the length of the segment and d the 
shortest length we can print. (For an ordi¬ 
nary laser printer, d is about 3 mils.) Then 
divide L into n = L/d intervals and use a 
delta code that yields the maximum den¬ 
sity according to Equation 3. 

However, such an increase in density 
comes only at a significant price. We must 
give up the self-clocking requirement and, 
consequently, many of the simple tech¬ 
niques for reading bar codes. We can de¬ 
code a bar code without self-clocking in 
one of three ways: 

(1) By capturing a complete symbol and 
then using image processing tech¬ 
niques to analyze it. If we know the 
symbol length, we do not need any 
scaling information. 

(2) By printing “timing” marks of a 
different color interleaved with the 
code markings. 

(3) By printing “timing” marks of the 


same color but in an adjacent zone 
of the substrate. 

The first solution requires more expensive 
equipment both for capturing the data and 
for processing them. (Current bar codes 
can be read by wand systems selling for 
about $100 per unit.) The second solution 
requires more expensive equipment for 
capturing the data but not for processing 
them. However, it requires a more expen¬ 
sive printing process. The third solution 
imposes a small increase in printing costs 
but requires more area, thus reducing the 
density of the encoding. It also requires an 
imaging type scanner, eliminating simple 
devices such as wands. 

It is doubtful whether such expenses can 
be justified, because Table 4 shows that 
(n,k) codes with large n come close to 80 
percent of the theoretical maximum. 
Therefore, the reduction in density because 
of self-clocking is not that serious. 

Even if you were willing to pay the high 
price required for a small increase in den¬ 
sity, it is still unclear whether you could 
actually achieve a net gain in information 
density. You can see the reasons by look¬ 
ing at the nature of the noise and distor¬ 
tions affecting the reading of information 
printed on a substrate. Most of the con¬ 
tamination of the information by noise 
occurs during the scanning of the printed 
medium, because you must deal with light 
reflected from a surface that might be 
poorly printed or dirty, experience inter¬ 
ference with ambient light or other print¬ 
ing, and so forth. Noise during the trans¬ 
mission of the data from the scanning 
device to a cash register or a computer 
terminal is much lower. We will show in 
the next section that the scanning noise 
affects mostly the edges of segments and 
has minimal effects in the middle of bars or 
spaces. 

If we do not wish to increase the total 
number of edges, then self-clocking elimi¬ 
nates very few useful combinations. For 
example, the unrestricted delta code for 
seven modules has 128 possible code 
words. The (7,2) code has 40 (if we ignore 
for the moment the bidirectionality re¬ 
quirement). Only 12 code words have one 
edge; two have none. The other 74 code 
words have more edges. Since the two code 
words with no edges could be confused 
with the background, we will gain only 12 
code words if we give up self-clocking and 
do not increase the sensitivity to noise. 

Electronic communications outperform 
printed codes for two reasons: the avail¬ 
ability of two values (+ or -) with respect to 
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Figure 5. Oscilloscope tracings of bar codes with a laser scanner. The input for 
the left-hand image was produced with a low-quality dot matrix printer and the 
input for the right with a high-quality, high-density printer. In this case, the 
pulse amplitude is an indication of the pulse width (see also Figure 6). 



Figure 6. Results from a simulator of bar code scanning waveforms running on a 
Sun-3/160 workstation. The thin lines denote the ideal waveform from a bar code 
scan. The dotted lines represent the distorted waveform output by the sensor. 
The double lines denote the apparent pulse locations and widths obtained by an 
adaptive threshold method. 


ground; and the availability of a clock in 
synchronous electronic communication 
channels. These are not available when we 
print on a substrate unless we incur the 
significant costs of a third color (both for 
printing and for reading). These problems 
are shared with other technologies, in par¬ 
ticular optical and magnetic recording,^'* 
where the recording polarities are binary. 

Sometimes we hear the following argu¬ 
ment: Since part of our problems are 
caused by the need to measure length, why 
not limit ourselves to looking for the pres¬ 
ence or absence of patterns without regard 
to their dimensions? However, in the ab¬ 
sence of a clock, pure detection is virtually 
impossible. We might not have to measure 
the length of bars, but we must measure the 
length of spaces. The only way around the 
lack of a clock is to allow only contact 
scanning (or at a fixed distance) and re¬ 
quire that the codes all have the same size. 
This is the case with optical and magnetic 
recording systems, as mentioned above in 
“The state of the art.” 

The only realistic solution for increas¬ 
ing the density of encoding in a rectangular 
area is to use the vertical dimension. This 
strategy has been implemented in the 
stacked bar codes discussed in the section 
“Other bar codes.” 

Noise and distortions 

The design of bar codes has been influ¬ 
enced by the type of noise and distortions 
encountered during their scanning. The 
distinction between noise and distortions 
is subtle but important: If we scan a bar 
code twice, the effects of distortions will 
repeat but the effects of the noise most 
likely will change. We will show that the 
effects are most significant near the edges 
between the bars and the spaces. 

A major source of distortions is ink 
spread. Bar codes are printed in two ways. 
On-demand printing demonstrates gener¬ 
ally low quality and has significant ink 
spread. In-advance printing, although of 
higher quality, still is not entirely free from 
ink spread. A cursory inspection of boxes 
in the supermarket might suggest that bar 
codes are sharply printed. However, for 
decoding we need to discriminate differ¬ 
ences in width of 0.01 inches — barely 
discernible by the human eye. We have 
already shown (in “Universal Product 
Code”) how ink spread has heavily influ¬ 
enced the design of decoding algorithms 
(see also Savir and Laurer'). Clearly, this 
distortion only affects the edges. 


Errors are also caused by the methods 
used for detecting bars and spaces. Be¬ 
cause of uncertainties about the contrast 
and because of problems with ambient illu¬ 
mination, it is advisable to look for changes 
in the intensity of the reflected light rather 
than in the absolute level of the light (auto¬ 
matic gain controls notwithstanding). In¬ 
deed, most bar code systems use edge de¬ 
tection or highly adaptive thresholding 
techniques that look, in effect, at the slope 
of the waveform produced when a bar code 
is scanned. While the ideal signal would be 
a set of rectangular pulses, the real signal 
has a rounded form because of convolution 
distortion. This term refers to the averag¬ 


ing of the signal due to the finite size of the 
beam spot and the delays in the electronic 
circuits. Such rounding changes the slope 
and causes significant errors even in the 
absence of noise. 

Figure 5 shows a photograph of oscillo¬ 
scope traces from the scanning of actual 
bar codes. This is a far cry from the crisp, 
alternating black and white bars seen by 
the human eye. 

The effects of distortion without noise 
appear in Figure 6, where we used a com¬ 
puter simulation. There, we assume with¬ 
out any loss of generality that the high 
levels correspond to bars and the low lev¬ 
els to spaces. 
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Table 7. Specific numbers of example in Figure 6. 


Bar Space 

Bar Space 

Bar 

Space 

Bar Space 

Bar 

Ideal Widths 0.50 0.50 

0.20 0.40 

0.40 

0.20 

0.20 0.20 

0.20 

Measured Widths 0.50 0.50 

0.30 0.31 

0.40 

0.29 

0.20 0.20 

0.20 




Figure 7. Possible errors in a binary string. 


Notice in Figure 6 that the second, 
fourth, and fifth pulses have the same real 
widths, but the waveform of the second 
pulse differs from the other two. As a 
consequence of the convolution distortion, 
the second pulse appears wider than the 
other two. The specific numbers of the 
example shown in the figure appear in 
Table 7. Both sets of widths are expressed 
in the same arbitrary units. Notice that a 
0.2 input width is mapped in one case to 0.3 
and in the other two to 0.2. Because of the 
severe distortions of very narrow pulses, 
the minimum width of modules used in bar 
codes must exceed the width of the mini¬ 
mum detectable pulse to compensate for 
the distortion. 

Using more sophisticated decoding 
techniques can help remedy the situation. 
For example, we could compare the width 
of a bar or a space not only to the widths of 
its immediate neighbors, but also to the 
widths of other code words. Such decoding 
might require more computing power than 
commonly used now, but it offers a way of 
tolerating higher code densities. 

In addition to those already mentioned 
above, many other sources of noise exist. 
Some are multiplicative, such as the 
speckle noise inherent to coherent laser 
illumination and that due to the paper 
substrate. Others are additive, such as the 
ambient illumination (low frequency noise 
in the case of artificial light and shot noise 
in the case of sunlight, the electronics of 
the scanner, etc. See Barkan and Sklar'^ 
and Barkan and Swartz'’ for more on these 
topics.). While the effects of those noise 
sources do not necessarily concentrate at 
the edges, they show no preference for the 
interior, either. Thus, overall we have 
greater sensitivity at the edges. 


Since most problems occur around the 
edges, we deal with signal-dependent dis¬ 
tortions and noise. That makes inappli¬ 
cable many of the analytical techniques 
used in electronic communications, where 
the noise is usually signal independent. 
Consider, for example, a message (stream 
of bits) of the form shown in the top row of 
Figure 7. A white square stands for a 0 and 
a black square for 1. In electronic commu¬ 
nications a 0 can be mapped into a negative 
voltage pulse and a 1 into a positive voltage 
pulse. The nature of noise is such that it is 
equally likely to misread a pulse at the ends 
or the middle of a run of similar polarity 
pulses. Thus, the distortions shown in the 
second and third rows are equally likely. 

We can encode the same sequence on 
paper by painting “modules” black for 1 ’s 
and white for O’s. The result will be a white 
band of two modules, a black of six, a white 
of two, etc. It is rather unlikely that a 
module in the middle of the blank band will 
be read as a white, but it is much more 
likely that one in the edges will. This prob¬ 
lem exists in other technologies as well, 
particularly optical and magnetic record¬ 
ing.There, most of the noise also occurs 
at the edges, giving rise to intersymbol 
interference. 

Bar code design: 
Preliminaries 

The design of a bar code involves the 
following major parameters: 

• the number, N, of distinct symbols that 
must be encoded; 

• the error rate, for rejections (when 
a code word is flagged as unreadable); 


• the error rate, E^, for substitutions or 
misdecodes (when one code word is 
read for another); 

• the density of information D measured 
as bits per inch; and 

• the number of modules n. 

The number of zones k in an {n,k) code is 
closely related to n. For symmetric codes 
we have the relation n=Ak-\. Usually N is 
given and we wish to minimize the two 
error rates, maximize the density, and keep 
n low. We wish to keep n low because the 
complexity of the decoding algorithm and 
the size of decoding tables increase with n. 
These parameters cannot all be optimized 
at the same time because they all depend on 
the module size X. We will discuss the 
possible trade-offs among them next. 

The trade-off between rejection and 
substitution rates, already well known 
from statistical decision theory, can be 
seen intuitively from the following ex¬ 
treme cases; If we set the rejection rate to 
100 percent, then we cannot have any 
substitution errors. Alternatively, if we do 
not mind how many substitution errors 
occur, we can have a zero rejection rate. 

The rejection and substitution rates’ 
relative sizes are controlled by a parameter 
in the decision step for a given overall 
decoding quality. Therefore, we will focus 
only on the substitution rate, assuming a 
zero rejection rate. If we can make that 
small during the design of the bar code, 
then we can make it even smaller by allow¬ 
ing some rejection errors. In bar code prac¬ 
tice we usually work with a 10“’ rejection 
rate and a lO"* substitution rate. 

An error typically occurs when we mis¬ 
read the width of an element in terms of 
modules. For example, instead of, say, 
3,2,1,1 (the code word for 0 in the UPC), 
we read 1,4,1,1 (the code word for 3 in the 
UPC). Clearly, the smaller the module size, 
the more likely it will have errors when 
reading the code, because a given amount 
of edge shift will constitute a higher per¬ 
centage of the total width if X is small. 
Moreover, the number of possible values 
to be discriminated should affect the error. 
Unfortunately, there have been no system¬ 
atic studies of these relationships. 

The Laplacian channel model looks like 
a reasonable approximation for the proba¬ 
bility of an edge shift equal to at least one 
module: 

p{X)=i^ ( 18 ) 

where T is a normalizing constant. If a code 
word has m edges, then the probability of 
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no errors is (1-/>)'" and the probability of 
having at least one significant edge shift is 

P(m;i{)=l~(l-p{X)r«mp{X),pQC)« l/m 
(19) 

We will use Equation 19 and the current 
bar code reading specifications to obtain 
an idea of the physical size of T. Assuming 
a UPC code word with four edges and an 
expected error rate of about 10“^, we find 
thatP(4^)=4-10’®. Substituting into Equa¬ 
tion 18 and taking the natural logarithm of 
both sides, we find 

-^<-61nl0-ln4 = 45.2 or X > 30.47 

For a minimum module width of 10 mils, 
this expression yields T equal to about 0.3 
mil. 

The probability of at least z significant 
edge shifts is 

PzimX) = I [ ^] p*( l-p)”-* = mY (20) 

with the approximation holding for z much 
smaller than m and p much smaller than 
1/m so that their product is much less 
than 1. 

The number of required code words N 
obviously imposes a lower bound on n. 
However, a comparison of Tables 3 and 6 
shows that n is never set at that minimum. 
It is usually set at a higher value to allow 
for some error detection because of redun¬ 
dancy. If we keep the module size fixed (in 
other words, we keep the error rate fixed), 
then an increase in n will lower the density. 
If we keep the code word length fixed so 
the density remains fixed, then it appears 
that an increase in n will increase the error 
rate. However, the number of available 
code words increases exponentially with n, 
and we can take advantage of this increase 
to introduce error detection and error cor¬ 
rection schemes. The concept has already 
been used empirically in all the earlier bar 
codes, which typically use only half of the 
available code words. 

In the next two sections we present a 
methodology for a systematic analysis of 
the trade-offs. The methodology is based 
on the analysis developed by Wang.'"* 
Consult that work for mathematical details 
of the development. 

Error detection is possible when we use 
only a fraction of the possible code words. 
We can set things up so that a single error 
will convert a code word into one not used. 
UPC and Code 39 have that property. If we 
arrange things so that it requires three er¬ 
rors to convert one used code word into 
another also used, then we can also do error 
correction. For each erroneous code word 


Table 8. Transformations of strings because of noise. 


Noise Effect 

Transformation 

Weight 


None 

xy^xy 

0 

(1) 

One edge shift to the left 

xy^{x-l)(y+l) 

1 

(2) 

One edge shift to the right 

xy^{x+l)(y-l) 

1 

(3) 

Warping or pair of edge shifts 

xy^(x-l)y 

1 

(4) 

Warping or pair of edge shifts 

xy-^ix+l)y 

1 

(5) 

Warping or pair of edge shifts 

xy-^x(y-l) 

1 

(6) 

Warping or pair of edge shifts 

xy->x(y+l) 

1 

(7) 

Combinations of edge shifts 

xy->other 


(8) 

Merging of three into one 

xyz-^(x+y+z) 

ly 

(a) 

Splitting of one into three 

x-^uvy,{u+v+y=x) 

TV 

(b) 


u we try to find another v from which u can 
be derived by one or two errors. Then we 
can assume that v is the correct version of 
u. We discuss such strategies next. 

Coding theory and 
bar codes: Diagonal 
distance 

The cornerstone of error correction tech¬ 
niques is the definition of a distance be¬ 
tween a pair of messages. The most com¬ 
mon such measure, the Hamming distance, 
equals the number of places two strings 
differ. If only a subset of all possible code 
words has been chosen, then a corrupted 
message is assumed to represent the near¬ 
est correct code word. 

In this article we use only elementary 
concepts of coding theory, which you can 
find in any text on the subject. The book by 
HilP’ is a particularly readable source. 

Bar codes are read as sequences of 
widths of bars and spaces. To compare 
such widths with each other, we must be 
careful about how the Hamming distance 
is computed. For example, the signal 324 
represents a bar with width 3 followed by 
a space with width 2, and then a bar with 
width 4. If the first element is a little “fat” 
from ink spread during the printing proc¬ 
ess, then the signal will probably be read as 
414. Using a general radix, the Hamming 
distance between 414 and 324 is 2, the 
number of differing elements. However, 
the correct Hamming distance is only 1, as 
shown by the binary representations: 

324 111 00 1111 

414 111101111 

Instead of having to go to the binary 


representation each time, we can introduce 
a different way of calculating the distance 
between the strings. Such a step is advis¬ 
able for four more reasons: 

(1) Most scanners detect the change of 
reflectance (edge) of the substrate rather 
than the existence of bars or spaces. There¬ 
fore, a single physical event will cause an 
edge shift. In contrast to communications 
systems, where the individual pulses are 
detected, the scanner does not see the 
underlying module structure. 

(2) The Hamming distance between the 
first string in Figure 7 and either the second 
or third is 1, while the second string is far 
less likely than the third. Coding theory is 
based on the premise that the smaller the 
distance, the more likely that one string is 
a distortion of the other. 

(3) In the case of width codes, there are 
no corresponding binary representations 
when the wide-to-narrow ratio is not an in¬ 
teger. 

(4) Due to scanning speed variation or 
substrate distortions (for example, a bar 
code printed on a plastic bag might stretch 
because of the elasticity of the plastic), an 
element can be shortened or lengthened. 

We call such effects warping errors, for 
example 

324 111 00 1111 

314 11101111 

In this case the distance of the binary 
representations cannot be measured by the 
Hamming distance because we have an 
insertion error. 

Therefore, it is best to define a metric 
that will give the answer 1 when a single 
physical disturbance occurs. 

Table 8 gives a partial list of the trans- 
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Table 9. Meaning of the minimum distance. 


Minimum Distance 

Meaning 

1 

Uniqueness 

2 

Single-error detection 

3 

Single-error correction (or double-error detection) 

4 

Single-error correction plus double-error detection 
(or triple-error detection) 

5 

Double-error correction 



Figure 8. Topology of the diagonal distance. Each axis corresponds to the length of 
an interval, and points of the plane correspond to pairs of successive intervals. 
A single edge shift causes a transition where the sum of x and y remains constant. 
The plot has been distorted so the geometrical distance corresponds to the string 
distance. Motions along perpendicular lines represent edge shifts. 


formations caused by noise and distortions 
during the reading of bar codes, x and y 
denote the widths of two successive ele¬ 
ments in one string, and T is a constant 
greater than 1. 

Given two strings X and Y, we can 
compute their distance on the basis of 
Table 8. The new distance is given by the 
minimum sum of weights of transitions in 
the table, which are needed to transform X 
to Y or vice versa. The weights in Table 8 
are based on the Laplacian channel model. 

We use the term diagonal distance to 
describe this new distance because of the 
geometrical interpretation shown in Fig¬ 
ure 8. There, the x and y axes represent 
successive elements (bars or spaces) of a 


string. Points along a vertical diagonal are 
equally close to their neighbors on the x 
and y axes. 

We can define the minimum distance 
di^in(C) of a code C as 

d nun(0 = min[d(v,w) .• v,w inC, v^w] 

where d(y,w) is the diagonal distance 
between v and w. The error-detecting and 
error-correcting capability of C is deter¬ 
mined by the d^^JC). Table 9 describes the 
meaning of the minimum distance for any 
encoding scheme. 

These concepts allow us to determine 
the error-detecting and error-correcting 
capability of any code and in particular 


UPC and Code 39. A look at the width 
pattern for UPC (see that section above) 
suggests that the minimum pairwise diago¬ 
nal distance is 2. For example, the code for 
the digit 7 is 1,3,1,2. A single edge shift 
may yield 1,2,2,2, which is not the code for 
any digit. One more shift might produce 
2,1,2,2, which is the code for the digit 2. In 
other words, it requires at least two edge 
shifts or one shift by two modules to con¬ 
vert one code word into another. There¬ 
fore, UPC has single-error detection capa¬ 
bility, meaning a single edge shifts results 
in an illegal code. The previous discussion 
(in the section on Code 39) also showed 
that the d^.^ for Code 39 equals 2, therefore 
Code 39 has single-error detection capa¬ 
bility, commonly referred to as self-check¬ 
ing. 

Note that we do not consider here the 
error control capability of the check-sum 
digit, since we focus on the encoding of 
bits or bytes on the printing medium rather 
than the overall encoding of information. 

Bar code design: 
Specifics 

Use of the diagonal distance has enabled 
us to prepare a set of tables to use for 
specific designs. If we insist on a minimum 
distance d between code words, then for 
each code word we select we must elimi¬ 
nate all code words lying in a sphere of 
radius (d-l)/2. 

Table 10 provides an approximate esti¬ 
mate of how many code words exist at a 
given radius away from another code word. 
For example, if we wish to have distance 5, 
then we must discard all codes at radius 2 
or smaller. For a (7,2) code. Table 10 
yields l-(-3-l-5.8, or about 10. Since a (7,2) 
code has only 20 code words, this would 
allow the encoding of only two distinct 
symbols — not of practical interest. On the 
other hand, for a (15,4) code and distance 
5, Table 10 yields 1+7+40.8, or about 49. 
Table 2 yields a total of 3,442 code words, 
so we can encode 3,442/49 or 70 distinct 
symbols. This would cover more symbols 
than most current codes provide and also 
allow double-error correction (see Table 
9). UPC, a (7,2) code, has a minimum 
distance 2 that translates into a radius equal 
to 0.5. This lies outside the table, but we 
extrapolate to 2 (that is, we can use only 
half the available code words). 

We proceed now to provide estimates of 
the density for given codes. Tables 11 to 13 
list the ratio of module width X over T and 
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Table 11. Design parameters for (7,2) codes. 



£=10-3 
XIT * 

D 

£=10-* 
XIT ' 

D 

£■=1 
XIT “ 

10-" 

D 

1 

16.012 

0.039 

29.828 

0.020 

43.643 

0.014 

2 

10.675 

0.040 

19.885 

0.021 

29.095 

0.014 

3 

8.666 

0.038 

15.573 

0.022 

22.481 

0.015 

4 

6.932 

0.032 

12.459 

0.018 

17.985 

0.012 

5 

5.651 

0.026 

10.256 

0.014 

14.861 

0.010 

Table 12. Design parameters for (11,3) codes. 


£=10-3 


£=10* 


£=10-'' 


XIT 

D 

XIT ' 

D 

XIT 

D 

1 

17.034 

0.042 

30.849 

0.023 

44.665 

0.016 

2 

11.356 

0.049 

20.566 

0.027 

29.776 

0.018 

3 

9.869 

0.050 

16.777 

0.029 

23.685 

0.021 

4 

7.896 

0.046 

13.421 

0.027 

18.948 

0.019 

5 

6.986 

0.043 

11.591 

0.025 

16.196 

0.019 

6 

5.988 

0.038 

9.935 

0.023 

13.882 

0.017 

7 

5.422 

0.034 

8.875 

0.020 

12.330 

0.015 

Table 13. Design parameters for (15,4) codes. 


£=10-’ 


£=10* 


£=10-" 


XIT ' 

D 

XIT ' 

D 

XIT 

D 

1 

17.707 

0.044 

31.522 

0.024 

45.338 

0.017 

2 

11.805 

0.054 

21.015 

0.030 

30.225 

0.021 

3 

10.618 

0.054 

17.525 

0.033 

24.433 

0.023 

4 

8.494 

0.054 

14.020 

0.033 

19.546 

0.0236 

5 

7.810 

0.052 

12.415 

0.032 

17.020 

0.0240 

6 

6.695 

0.049 

10.641 

0.031 

14.589 

0 0227 

7 

6.261 

0.046 

9.715 

0.029 

13.169 

0.021 

8 

5.566 

0.041 

8.635 

0.026 

11.706 

0.020 

9 

5.189 

0.038 

7.952 

0.024 

10.715 

0.018 


Table 10. Average number of code words 
at a given radius for various (n,k) codes. 


Radius 

(7,2) 

(11,3) (15,4) (19,5) 

1 

3.0 

5.0 

7.0 

9.0 

2 

5.80 

19.3 

40.8 

70.4 

3 

4.80 

35.6 

122 

297 

4 

3.40 

51.2 

275 

931 

5 

1.30 

48.7 

430 

2,086 

6 

0.700 

42.0 

562 

3,777 

7 


25.1 

573 

5,473 

8 


15.9 

522 

6,831 

9 


5.57 

382 

7,191 

10 


2.62 

266 

6,792 

11 



141 

5,520 

12 



76.0 

4,143 

13 



24.2 

2,643 

14 



9.47 

1,594 

15 




763 

16 
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the corresponding density D for a set of 
(njc) codes and minimum distances 
The maximum density value is highlighted 
in bold. (Complete design tables appear in 
Wang.'"') We illustrate their use with an 
example. 

Example. We need 44 code words. We 
select = 3 so that we can have single¬ 
error correction (according to Table 9). 
Then the radius should be 1. We start with 
an (11,3) code. According to Table 10, the 
sphere volume is 1 + 5 = 6, while the total 
number of code words, according to Table 
4, is 252. Therefore, the number of avail¬ 
able code words is 252/6 = 42. This is 
slightly less than the desired 44, but we 
keep it. The values of Table 10 are approxi¬ 
mate averages, and we should be able to 
select 44 code words that will allow us 
error correction. 

The density for this code is found from 
Table 12 to be maximum ford . =3.For£ 
= 10-* we have XIT = 16.78 and D = 0.029 
bits per length T. For T = 0.6 mil this yields 
48 bits per inch and module size X = 
16.77x0.6 or 10 mils. 

For the same goal we can try another 
combination: d^.^ = 5 (double-error correc¬ 
tion) and a (15,4) code. We already saw 
that this yields 70 code words, so we have 
more than enough. From Table 13 we find 
that for E^=\ 0* the ratio X/T = 12.4 and the 
density is 0.032 bits per length T or 55 bits 
per inch with module size equal to 7.5 mils. 
This density is 14 percent higher than that 
obtained with a (11,3) code and has been 
achieved without an increase in the error 


rate. It is an engineering question whether 
this increase in density is justified by the 
increase in the decoding cost caused by 
going from 11 modules to 15. 

Table 11 provides an interesting insight 
on UPC. The maximum density for a (7,2) 
code is achieved for = 2. This is exactly 
the value used in UPC, so we might be 
justified in calling UPC an optimal density 
(7,2) code. 


W e have provided a method for 
applying the results of coding 
theory to bar codes. As new 
applications demand new types of bar 
codes, the results presented in this article 


make it possible to optimize the informa¬ 
tion density of the new codes under realis¬ 
tic constraints. The methodology is par¬ 
ticularly useful for the design of two- 
dimensional or stacked bar codes. ■ 
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High Speed Protocols Willibald A. Doeringer 


Audience: Intended for research and development 
personnel who may have had some exposure to 
networking issues in general but would like to increase 
their knowledge in the area of transport protocols, 
particularly for the coming generation of high-speed 
networks. 

Lecturer: Dr. Doeringer holds MS and PhD degrees 
from the University of Karlsruhe, FRG. He has lectured 
on operations research at the University of Ulm, FRG 
and has held senior technical and engineering 
management positions in the communications 
department of a large German software company. At 
present, he works as a research scientist at the IBM 
Zurich Research Laboratory with special interest in 
communication systems architecture and high-speed 
protocols. 


Outline: Enabled by progress in fiber optics and VLSI 
technologies, networks which offer increased 
transmission capacity at decreasing error rates are 
becoming available. New applications could use this 
bandwidth but software protocol processing rates have 
fallen behind the raw transmission speed. This tutorial 
presents a comparative survey of recent techniques 
used at the transport layer in a representative set of 
protocols, most of which were designed to improve the 
protocol processing rate. The protocols addressed 
include APPN, Datakit, Delta-t, NETBLT, OSI/TP4, 
TCP, VMTP, and XTP. Suggestions of which of those 
techniques seem the most promising for use in 
high-speed networks are also included. This tutorial 
covers the basic components of any transport protocol; 
connection management, acknowledgements, flow 
control and error recovery. 


Packet Video Willem Verbiest and Luc Elewaut 


Audience: First, the tutorial is intended for students 
and researchers who are starting to investigate or are 
interested in learning about Packet Video. The tutorial 
will provide them with a well-rounded introduction to 
this field. However, the tutorial is also well-suited for 
people already involved in one of the Packet Video 
areas, as it will help them place their work in the correct 
context and to compare it with other techniques, e.g., 
those under discussion in the standardization bodies. 
Further, the tutorial is intended for specialists in video 
coding or networks who are interested in seeing how 
both domains merge within the Packet Video domain. 
Some prior knowledge on basic concepts in video 
coding and/or networks is recommended. 

Lecturers: Willem Verbiest was born in Ghent 
(Belgium) in 1958. He received a BS degree in nuclear 
physics in 1981 from the Ghent State University. After 
a short period at CERN, he joined the Bell Telephone 
Mfg. Co.'s research center ini 982. In 1984, he started 
research on Variable Bit Rate video coding, resulting in 
a prototype of a VBR video codec connected to an 
ATM network early 1987. Currently, he is heading 
research on the broadband subscriber installation in 
access, including VBR coding, ATM SPN's and the 
optical subscriber loop. 

Dr. Luc Elewaut was born in Ghent (Belgium) in 1961. 
He received an M.S.degree in electrical engineering 
from the Ghent State University (RUG) ini984. From 
1984-1987, he was a research assistant in the 
"Laboratory of Electromagnetism and Acoustics" (RUG) 


where he worked on numerical modeling of gallium 
arsenide engineering from the same university. In 
1988, he joined the Alcatel Bell Telephone's research 
center. His current research interests are broadband 
terminals and terminal adapters, including VBR video 
coding standardization aspects. 

Outline: The main objective of the tutorial is to 
provide an overview of what has become a new 
research domain in telecommunications: Packet Video. 
Therefore, an extensive survey of different packet 
video techniques and concepts will be given as well as 
an overview of activities in this field. However, it is not 
the objective to go into a detailed analysis of the 
different techniques. Instead, basic principles and 
system aspects will be discussed. Pros and cons will 
be indicated and comparison with other techniques will 
be made. For those who want to probe further, an 
extensive reference list will be provided. Substantial 
time will be allotted to an overview of worldwide packet 
video activities. Included will be a list of research 
organizations (universities, industry & administrations) 
involved in packet video, of their activities and the 
direction followed. Standardization activities (e.g., 
ETSI, CCITT, T1S1) will also be reported on. Topics will 
include asynchronous transfer mode, variable bit rate 
coding, network protocols for packet video, layered 
coding cell loss handling, standardization issues, 
overview of worldwide Packet Video research, 
experiments and field trials, and Packet Video 
references. 
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Audience: Intended for engineering research, 
development, and management personnel who are 
interested in learning the fundamentals of Broadband 
ISDN. No previous exposure to B-ISDN is assumed. 
Lecturer: Richard Vickers was educated in the United 
Kingdom. He received his BSc in electrical engineering 
: from the University of Wales in 1967. He has worked at 

[ BNR in Ottawa, Canada since 1977, where he has 
I worked on a variety of technologies including fast 
circuit switching exploratory and optical loop system 
exploratory. More recently he has been responsible for 
the development of exploratory ATM multiplex 
equipment. He is currently Manager of B-ISDN 
Architecture and Development and among other 
activities is chairman of the T1 SI .5 Subworking Group 
on ATM Aspects of B-ISDN and is an active contributor 
to the development of B-ISDN recommendations in 
CCITT Study Group XVIII. 


Outline: Broadband ISDN will provide a major 
enhancement of communication capabilities to the 
end-user. Broadband ISDN will encompass more than 
simply a broadband transport facility, it will also provide 
more flexible call structures, and more sophisticated 
network services. This tutorial will cover a number of 
aspects of Broadband ISDN. An overview of broadband 
applications and other driving forces will be given. This 
overview will be followed by a description of Broadband 
ISDN protocol layers; physical, transport, adaptation, 
signaling, and call control will be covered. The next 
topic will address the building and engineering of 
B-ISDN itself. The final topic will be an overview of some 
peripheral issues to Broadband ISDN, including user 
protocols and regulatory/tariff issues. 


Practical Perspectives on OSi Applications Christopher W. Moore 


I Audience: Intended for professionals interested in 
planning or implementing OSI networks. Topics are of 
special interest to those needing an understanding of 
the pros and cons of the OSI application environment 
and particular applications such as electronic mail and 
directory services. A basic familiarity with networking 
and OSI is assumed. Detailed knowledge of the 
protocols is not required. 

Lecturer: Christopher (Chris) Moore is a Product 
Marketing Manager with Touch Communications in 
I Campbell, California, where his responsibilities include 
I X.400 and X.500 products. He is involved with national 
I and international working groups in the areas of 
Directory and Messaging and presently serves as 
chairman of the U.S. National Institute of Standards and 
Technology (NIST) Implementors Workshops special 
Interest group on Directory Services. Prior to joining 
Touch, Moore was Manager of OSI Development with 
the Wollongong Group, Inc. 


Outline: Those attending will achieve a thorough 
understanding of the OSI application environment and 
the technology involved in developing OSI networks. 
A basic look at the features and flaws of the OSI upper 
layers, Session, Presentation, Abstract syntax tools 
and Application Service Elements will be given. 
Additionally, a foundation by which one can make 
decisions regarding the "popular" OSI applications 
such as Message Handling and Directory Services will 
be provided. Topics will include; basic concepts, upper 
layer Infrastructure, session layer services, abstract 
syntax concepts, presentation layer services, 
application service elements, and "popular" 
applications. 
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Network Control and Management Jerry McDowell 


Audience: Intended for network managers, planners 
and designers. Any department level manager who 
makes use of communications systems in his/her 
department should also attend. 

Lecturer: Jerry McDowell is President, McDowell 
Romero, a management consulting firm in Carmel 
Valley, CA, specializing in management of voice and 
data communication networks, their products, and 
services. Mr. McDowell holds degrees in Business 
Management and Electrical Engineering, and for the 
past two decades has been probing the intricacies of 
data and telecommunication networks. He has worked 
intimately with companies such as Wang, IBM, Gould, 
and Paradyne. As a principal of McDowell Romero, he 
has been an authoritative voice lecturing and 
presenting new technical papers, consulting, and 
working with other communication industry experts to 
evaluate and set new standards for both local and wide 
area networks. 


Outline: Minimal downtime, rapid response to user 
inquiry and accurate data information at low cost are the 
key mandates for the network manager. As 
communication networks grow more complex, the 
probability of failure increases; and as these networks 
grow larger, the task of identifying the source of 
problems becomes more difficult. The network 
manager needs a set of "tools" that provide effective 
access to the network components - both local and 
remote - for continuous monitoring and fast fault 
detection and isolation. This tutorial will provide a 
foundation upon which the network manager can build 
a comprehensive approach to network management. 
Topics will include: The operational considerations of a 
network manager and specific techniques used by 
successful network managers to achieve the highest 
degree of service level in networks. Why many 
companies are turning towards a centralized network 
management approach for both their voice and data 
networks. Integrated multivendor network 
management. What the primary approaches to network 
management and control systems have been, are, and 
what they will be. The directions of IBM (Netview), DEC 
(EMA), AT&T (UNMA), OSI and others. The resources 
required of a network manager to keep a network up 
and running and how to get these resources. 


Large Broadband Lightwave Networks Anthony S. Acampora 


Audience: Intended for systems engineers, 

hardware and software designers, R and D managers, 
and market planners who seek an understanding of 
lightwave networks for integrated voice, data, image, 
and video telecommunications. 

Lecturer: Anthony S. Acampora, Professor of 
Electrical Engineering and Director, Center for 
Telecommunications Research, Columbia University. 
He joined the faculty at Columbia in 1988 after a 
20-year career at AT&T Bell Laboratories mostly spent 
in basic research, where his interests were radio and 
satellite communications, local and metropolitan area 
networks, packet switching, communications systems, 
and lightwave networks. His most recent position at 
AT&T Bell Laboratories was Director of the 
Transmission Technology Laboratory. 


Outline: Because multi-user networks based on 
lightwave technology can potentially supply a pool of 
capacity up to several terabits/sec., unique network 
approaches are required to allow for optimum user 
access. This lecture reviews relevant technologies 
including active and passive components, detector 
performance, and fundamental limits. Access 
techniques, architectures, and performance of 
multichannel, ultra-high capacity packet networks are 
then explored. Among the basic approaches 
considered are wavelength division multiplexing using 
coherent optics, time division multiplexing using 
picosecond pulses, and space division multiplexing 
using fast electronic packet switching technology. 
Multihop mesh networks are presented as a practical 
approach for modularly synthesizing terabit networks 
using conventional, lower speed lightwave and 
electronic technologies. Lower capacity, single 
channel networks based on bus and ring topologies 
are also discussed, along with a range of new 
bandwidth intensive applications and services. 
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San Francisco 

San Francisco is laden with so many points 
of interest that the typical visitor gets the 
feeling that there is almost too much to see 
and do. San Francisco offers something for 
the curious, the adventurous, and the history 
buff alike. It is a mecca for shoppers and a 
gourmet's delight. Among its famous 
attractions are: Alcatraz Island, Chinatown, 
Golden Gate Park, Exploratorium, and 
Lombard Street. Within easy drives from San 
Francisco are the Napa/Sonoma wine 
country, Carmel-by-the-sea and Muir woods. 
One way that you may want to begin seeing 
San Francisco is on a cruise, and because 
the city is so compact it is ideal for strolls. 
You can explore Golden Gate Park, Union 
Square, Fisherman's Wharf (Pier 39, the 
Cannery and Ghirardelli Square), 
Chinatown, and Japantown. 


Hotel NIkko 

Hotel Nikko is one of San Francisco's pre¬ 
mier hotels. The hotel is a 30 minute ride 
from the San Francisco International Airport. 
Taxi fare is approximately $30 and the SFO 
Airporter is $5 one way. The SFO Airporter 
coach marked 'Hilton' stops at the Hilton Ho¬ 
tel, which is across the street from the Hotel 
Nikko; it leaves at 30 minute intervals from 
the airport baggage claim/curb loading zone. 
The phone number of the SFO Airporter is 
(415) 673 2433. 

Airline Reservations 
Northwest Airlines has been selected as the 
official carrier for all attendees and is offering 
a 5% discount off the lowest available fare for 
which you qualify or a 40% discount from the 
adult, round trip, coach class fare. For further 
details call Northwest at (800) 328 1111 and 
mention IEEE Infocom (ID Code 16268). 
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A standard for extremely low frequency magnetic fields 


Fletcher J. Buckley 

In 1854, John Snow plotted the loca¬ 
tion of deaths from cholera occurring in a 
neighborhood of London, together with 
the location of the area’s water pumps. 
Based on his observations,' Snow had the 
handle of the Broad Street water pump 
removed, thus ending a neighborhood 
epidemic that took more than 500 lives in 
10 days. 

In a manner similar to Snow’s method¬ 
ology, Wertheimer and keeper in 1979 
plotted the deaths from cancer in the 
Greater Denver area, together with the 
location of electric power utility trans¬ 
formers. Based on their observations, 
they discovered a significant correlation 
between the location of “high-current 
configuration” wires and the location of 
homes of those dying of cancer. They 
postulated^ that the observed rise in the 
occurrence of cancer was due to the 60- 


Hertz magnetic fields from the power dis¬ 
tribution networks. The finding was 
strongest for children who had lived at the 
same address all their lives. 

In 1982, Tomenius reported that chil¬ 
dren living in homes with a 50-Hz mag¬ 
netic field strength of 3 milligauss or 
higher developed cancer at a rate twice 
that of the control population. Tomenius 
confirmed his findings in his 1986 re¬ 
port,^ which stated that the relative risk of 
cancer in people living at locations with 
measured field strengths of 3 mG or 
higher was more than 2.1 those in a con¬ 
trol population. 

From December 1, 1983, to June 30, 
1986, Savitz performed an extensive in¬ 
vestigation for the New York Power Proj¬ 
ect, replicating and extending the Wer- 
theimer-Leeper effort. As part of his re¬ 
port, Savitz concluded'' that “leukemia 


cases, especially for low-power mag¬ 
netic fields, consistently had higher ex¬ 
posures than controls, with odds ratios 
above 2.1 for exposures to 2.5 + mG.” In a 
further paper^ in 1988, he reported that, 
with a cutoff ratio of 2.0 mG, the odds ra¬ 
tio was 1.9 for leukemia, 2.2 for lym¬ 
phoma, and 3.3 for soft-tissue tumors. 

A wide range of the experimental ef¬ 
fects of extremely low frequency (ELF) 
electromagnetic fields has been docu¬ 
mented on laboratory animals and cell 
cultures at field strengths and frequen¬ 
cies relevant to human exposures near 
power lines.'^ What these effects imply 
and what should be done about them is a 
matter of extensive debate among the af¬ 
fected parties. 

All of this is part of the growing contro¬ 
versy sweeping the medical and the elec¬ 
trical engineering professions on the bio¬ 
logical effects of ELF magnetic fields — 
those with frequencies in the vicinity of 3 
to 3(X) Hertz.* The stakes are high since 
these fields can be directly caused by 

(1) the power lines that everywhere bi¬ 
sect our countries, 

(2) the video display terminals whose 
vertical deflection coils produce 
60-hertz magnetic fields,** and 

(3) the electric heating cables in elec¬ 
tric blankets, electrically heated 
waterbeds, and radiant ceiling 
heat. 

Complexity factors. The topic is fur¬ 
ther complicated by a number of factors: 

• Inconsistent results. For example, in 
1980, Fulton et al.’ attempted to repro¬ 
duce Wertheimer and keeper’s study and 
reported that there was no correlation be¬ 
tween electrical wiring configurations 


* To be precise, ELF refers to the frequency band of 30 
to 300 Hz. For this discussion, the band is being ex¬ 
tended to 3 Hz. 


** For an opposing view on the biological hazards as¬ 
sociated with VDTs, see K. Foster, “The VDT 
Debate,” Amer. Scientist, Mar.-Apr. 1986, pp. 164- 


Standards for public key encryption 
algorithms to be discussed in Oakland 


A meeting will be conducted Fri¬ 
day, May 4, in Oakland, California, 
to discuss the standardization of 
public key encryption algorithms. 
Sponsored by the IEEE Technical 
Committee on Security and Pri¬ 
vacy, the meeting will be held just 
prior to the 1990 IEEE Symposium 
on Research in Security and Pri¬ 
vacy, set May 7-9 also in Oakland. 

All those interested in discussing 
and participating in the develop¬ 
ment of this standard are encour¬ 
aged to attend. 

Several standards working group 
are contemplating the use of public 
key algorithms as part of their 
protocols. These algorithms are 
being considered for use in key 
management for key exchange, for 
nonrepudiation as digital signa¬ 


tures, and for authentication as digital 
certificates. The algorithms under 
consideration are Diffie-Hellman, 
ElGamal, and RSA (Rivest-Schamir- 
Adelman). 

The primary discussion at the meet¬ 
ing will focus on determining if a stan¬ 
dard is necessary and defining the 
scope of the standards activities. The 
proposed objective of the standard is 
to standardize the proper implemen¬ 
tation of the algorithms. 

For more information on this activ¬ 
ity, contact Jon Graff of Cylink Cor¬ 
poration at (408) 735-5878. 

The meeting will be held from 9 
a.m. to 5 p.m. at the Clairmont Resort, 
Ashland and Domingo Avenues, 
Oakland, CA 94623, phone (415) 
843-3000. Special room rates have 
been negotiated for attendees. 
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and childhood leukemia. The same year, 
and in the same publication in which Ful¬ 
ton’s study was published, Wertheimer 
and Leeper* reported their analysis of 
Fulton’s paper, as did Bryan.^ Wer¬ 
theimer and Leeper found problems with 
Fulton’s efforts, while Bryan pointed out 
that Fulton’s study assumed that (1) the 
strength of the magnetic field was in¬ 
versely proportional to the square of the 
distance rather than inversely propor¬ 
tional to the distance itself and (2) the 
field strengths are always numerically 
additive rather than this applying only if 
the currents in the wires were going in the 
same direction. Otherwise, the fields 
tend to cancel each other. 

• The sample sizes of some of the stud¬ 
ies. For example, Tomenius'® reported 
that for people who had lived in the same 
dwelling since birth with a magnetic field 
of 3.0 -I- mG, the relative risk from cancer 
was 5.4. The sample size of this particular 
group, however, was only 10. 

• Biased summaries. Every summary 
of what others have reported could be 
considered biased (including this one), 
and the reader might well be advised to re¬ 
fer to the basis on which each conclusion 
is stated. Some summaries may be biased 
by omission. For example, consider the 
Electric Power Research Institute’s re¬ 
print, “EMF and Human Health,” pro¬ 
vided by an EPRI spokesperson from the 
October/November 1987 EPRI Journal. 
This reports the Fulton study as being a 
reason for dismissing the Wertheimer- 
Leeper findings while not reporting the 
rejoinders that appeared in the same year 
in the same professional journal. 

• Other possible causes. The studies 
made to date can always be challenged by 
the consideration of other factors. For ex¬ 
ample, was the rise in cancer due to the 
ELF magnetic fields or to the close prox¬ 
imity of the toxic waste dump that con¬ 
tained prganic solvents? As the studies 
have progressed, these concerns appear 
to have been reduced. 

• The source of funds for research. Re¬ 
search costs money, and finding the 
money to support the activities associ¬ 
ated with this topic can be a challenge. 
This can be further complicated by the 
source of the funds. Interested groups are 
providing funds; unfortunately, there is 
always the perception that, if the conclu¬ 
sions are at variance with the goals of the 
funding organization, the funds will dry 
up. For credibility of the results, there¬ 
fore, either some disinterested source of 
funds is needed, or some form of admin¬ 
istering the funds to remove any percep¬ 
tion of institutional bias is required. 


• Estimations of the long-term, low- 
level dosage to which the subjects have 
been exposed. This is complicated since 
the studies that have been made using 
humans have, by necessity, been retroac¬ 
tive in nature. (It is not feasible, for ex¬ 
ample, to run a long-term controlled can¬ 
cer experiment that uses human sub¬ 
jects.) This implies the need to estimate 
long-term, low-level exposure doses 
from either the configuration of wires or 
from a single, one-time measurement of 
the field strength (or both). As a further 
complication, people move from place to 
place in an uncontrolled manner, so esti¬ 
mating the effects at one location might 
be inaccurately extrapolated to a total 
long-term exposure dosage. 

• Complexity of the field. The compe¬ 
tency of those making authoritative state¬ 
ments is always a question. The topic of 
the health effects of ELF magnetic fields 
is one that crosses many professional dis¬ 
ciplines. Clearly, electrical engineers are 
involved. Clearly, elements of the medi¬ 
cal profession are also involved, espe¬ 
cially the specialities of epidemiology 
(the branch of medicine that deals with 
the origin, nature, pathology and preven¬ 
tion of epidemic diseases) and oncology 
(the science of tumors). It is not clear in 
all cases that those making authoritative 
statements have been speaking in areas of 
their expertise. 

• Authoritative statements. For ex¬ 
ample, the US Activities Board of the 
IEEE, in a 1988 entity position statement, 
said that there was not enough relevant 
scientific data to establish whether com¬ 
mon exposure to power-frequency fields 
should be considered a health hazard." 
On the face of it, the cited report, issued 
by a major component of the IEEE, is a 
very powerful document. Examination of 
this indicates the following difficulties: 
(1) The report is not based on a direct re¬ 
view of primary sources but rather on a 
review of six other reports. As noted 
above, in dealing with this topic, with 
strong feelings held by so many, reliance 
on sources other than primary sources, 
can lead to error; and (2) the process of 
preparation of the USAB statement was 
in accordance with Section 15 of the IEEE 
Policy and Procedures Manual, but in 
this context that process appears to con¬ 
tain flaws. Due process in the American 
National Standards Institute sense (par¬ 
ticipation by all those having an interest 
in the topic, etc.) appears to be lacking. 
The groups consisted of members who 
are nominated and approved. 

As a further example, the International 
Radiation Protective Association has 
Stated‘S that the interim guidelines for 
long-term exposure to magnetic field in¬ 


tensity should be 0.1 millitesla (1 gauss). 
These guidelines decry the Wertheimer- 
Leeper and Savitz studies, saying that 
since the studies were carried out in the 
same geographical location, the results 
cannot be generalized. These guidelines 
do not mention the Tomenius results. 

The National Electrical Manufacturers 
Association, as part of a two-page bro¬ 
chure,'^ makes the following statement: 
“On the whole, there appears to be strong 
evidence against the induction of serious 
ill effects to health from exposure to 60- 
Hz electric and magnetic fields.” Spe¬ 
cific inquiries made to NEMA concern¬ 
ing the basis on which that statement was 
made have not been productive. 

• Resolution of the precise manner in 
which ELF magnetic fields could cause 
cancer. There does not appear to be a 
clear trace of the chain of events from 
long-term, low-level exposure to the oc¬ 
currence of cancer. It is not clear if the 
ELF field itself causes the cancer or 
merely creates an environment that pro¬ 
motes the growth of cancerous tumors. 
How it might create that environment ap¬ 
pears to be a matter of informed specula¬ 
tion. 

• Costlbenefit trade-offs. To come to a 
consensus of what should be done, an as¬ 
sessment of the risks incurred from the 
threat is required. In terms of common 
sense and current realities, it does not ap¬ 
pear reasonable to tear down all the exist¬ 
ing electric power transmission and dis¬ 
tribution lines throughout the world to 
avoid one additional occurrence of can¬ 
cer. These lines might indeed be tom 
down if they would cause half the world’s 
population to die of cancer, but that does 
not appear to be the case. 

What is to be done. Despite all the 
complicating factors, a consensus is aris¬ 
ing that something is wrong — that there 
is a causal relationship between long¬ 
term, low-level exposure to ELF mag¬ 
netic fields and an increased risk of ac¬ 
quiring cancer and other health effects.* 
The difficulty is to determine what 
courses of action reasonable and prudent 
people should take. One course of action 
proposed by some groups is that nothing 
should be done except further research. If 
this course of action had been taken in 
1854, the cholera epidemic would have 
continued to rage in central London until 
1883, when Robert Koch isolated and 


* For example, see “Biological Effects of Exposure to 
Electromagnetic Fields," B. Miller, Product Safety 
Newsletter reprint from Professional Safety, Aug. 
1989, American Society of Safety Engineers; and 
“Power Play," D. Noland, Discover, Dec. 1989, pp. 62- 
68. 


96 


COMPUTER 







identified the cholera bacteria.''' 

There is clearly a need for further re¬ 
search. It does make sense, however, to 
act in a manner that would minimize the 
risks of additional cancer cases where 
such actions would not be inordinately 
expensive. How much is enough requires 
judgments to be made and, at the present 
time, with the lack of any standards, those 
Judgments are being made in the courts. 

To move forward, we should 

(1) promote policies of free and frank 
disclosure about the current state of the 
controversy to all those who may he af¬ 
fected. The ethical validity of continuing 
to expose people to the effects of ELF 
magnetic fields without their informed 
consent is highly questionable; and 

(2) adopt a course of prudent avoid¬ 
ance. There are things that can be done 
now at little or minimum cost that would 
provide future relief.* 

Free and frank disclosure. This would 
imply, for example, that organizations 
whose workers might be at risk should 


• For a detailed discussion of options and, in particu¬ 
lar, prudent avoidance, see Nair, Morgan, and Florig 
in the sidebar, “To go further.” 


make them aware of the potential dangers 
from ELF magnetic fields and initiate a 
measurement and monitoring program to 
quantify the degree of risk from these 
fields. 

Some prudent avoidance actions. 

From an electrical engineering stand¬ 
point, no state-of-the-art breakthrough is 
required to configure the electric heating 
cables in electric blankets, waterbeds, 
and ceilings to minimize ELF magnetic 
fields. Recognizing the minimal cost in¬ 
volved, these are things that should either 
be done by industry or else be required by 
local governments without a detailed 10- 
year research program. Similar actions 
are being taken in the prohibitions cur¬ 
rently being enacted to ban the use of 
lead-based solder in construction of 
household water supplies. 

Guides could be provided to, for ex¬ 
ample, the building industry, the utilities, 
and the communications and computer 
industries to recommend specific tech¬ 
niques to reduce ELF magnetic fields in 
all new construction. 

Design and construction techniques to 
minimize the effects of ELF fields from 
VDTs is also well within the state of the 
art. The additional costs of incorporating 
these items in large-scale production 
equipment runs is considered minimal. 


To go further 


(1) There is extensive literature on 
this topic. An initial list should include; 

• M. Coleman and V. Beral, “A Re¬ 
view of Epidemiological Studies of 
the Health Effects of Living Near or 
Working With Electricity Generation 
and Transmission Equipment,” Int’l J. 
Epidemiology, Vol. 17, No. 1, 1988, 
pp. 1-13. 

• P. Brodeur, Currents Of Death, Si¬ 
mon and Schuster, New York, N.Y., 
1989. (This book is considered quite 
controversial by some.) 

• I. Nair, M. Morgan, and H. Florig, 
“Biological Effects of Power Fre¬ 
quency Electric and Magnetic 
Fields," prepared for the Office of 
Technology Assessment by Dept, of 
Engineering and Public, Policy, Car¬ 
negie Mellon Univ., Pittsburgh, PA 
15213 (copy available from the 
Superintendent of Documents, Gov¬ 
ernment Printing Office, Washington, 
DC 20402-9325, GPO stock number 
052-003-01152-2). 


• M. Morgan et al., “Electric and Mag¬ 
netic Fields from 60-Hertz Electric 
Power; What Do We Know About Pos¬ 
sible Health Risks,” 1989, Department 
of Engineering and Public Policy, Car¬ 
negie Mellon Univ., Pittsburgh, PA 
15213. 

(2) The Bioelectromagnetics Soci¬ 
ety is a multidisciplinary organization 
founded in 1979 to study the biological 
effects of environmental electromag¬ 
netic fields. Interested persons should 
contact: The Bioelectromagnetics So¬ 
ciety, 120 W. Church St., Suite 4, 
Frederick, MD 21701, phone (301) 
663-4252. 

(3) The IEEE Standards Board is 
considering establishing a standards 
coordinating committee on this topic. 
Those interested in participating in the 
efforts of that activity should contact 
Andrew Salem, IEEE Standards Dept., 
445 Hoes Lane, PO Box 1331, Piscata- 
way, NJ 08855-1331. 
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Motorola Cellular, we see 
no end in sites. 


Stretching from the U.S. throughout the Far East, Latin Motorola Cellular can offer its customers...and your 
America and Europe, Motorola cell sites cover the world. engineering career If you want a career as dynamic as our 
In fact, the company that pioneered cellular communica- growth, set your sites on one ofthe opportunities on the op¬ 
tions is now outdistancing all competitors comlcined. We’re posite page. 

We offer an attractive salary, a comprehensive benefits 
packageandoppohunfe&pofes^’onalgravth, Forinv 


four-cell reuse plan that supports 
more voice channels with fewer 
cell sites. 

And with just 1% of the global 
cellular market developed, the op- 
prtunities at Motorola Cellular have 
just begun. We’re developing the 
most advanced software, switch¬ 
ing equipment and radio tele¬ 
phone exchanges. We’re 
constantly modifying, up¬ 
dating and simplifying 
systems while enhanc- 
ing RF sector-sharing 
capabilities. 

Flexibility, capability and 
expandability.. .that's what 
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1501 West Shure Drive, 
Arlington Fleights, IL 
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(our 24-hour FAX line). To 
access our On-Line Ca¬ 
reer Netwcrkfrom your PC, 
dial (508) 263-3857 press 
return twice, and key in 
password LEGACY \Ne are 
an equal opportunity/affir¬ 
mative action employer 
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SOFTWARE: Real-time software develop¬ 
ment using C, UNIX* Pascal, Ada, assembler 
and structured design; experience in softwar6 
quality, metrics, or testing; CASE software 
tools (Sun, Apollo); design, programming 
and s^em debugging for telephone digital 
switching or data communication systems; 
assembler and high-level structured 
languages; hardware diagnostics; object 
oriented design, C-i--)-; software develop¬ 
ment tools such as Teamwork and Interleaf; 
ASN.1 (AbstractSyntax Notation); data com¬ 
munications protocols (CCITT *7, OSI, X.25, 
X.75, PAD, LAPB, U\PD, Ethernet, ISDN, 
CCITTVseriesmodem.groupSfax); model¬ 
ing and simulations (GPSS, SIMSCRIPTand 
other simulation tools). BSEE/BSCS/BSCE or 
equivalent. Respond to Dept. SW. 

ELECTRICAUCOMPUTEH:Analog and RF 

circuit design, receiver or transmitter RF cir¬ 
cuits; LjCD display technology, acoustics, and 
8-bit microprocessor software; infrared and 
fiber optics; low speed data; digital modula¬ 
tion; 900 Mhz RF power amplifier design with 
hybrid or microstrip circuitry; RF device 
development with device vendors; parallel 
and/or push-pull RF amplifier design at 900 
Mhz or UHF; A/D and D/A convertors; RF pro¬ 
pagation; passive and active filter theory; 
microwave antenha design; UL, EMIandRFI 
requirements; HP3062 test system; HP9000; 
digital hardware, microprocessor applica¬ 
tions and interfaces; digital switching 
technology; firmware development methodo¬ 
logy; PCM and digital telephony; digital signal 
processing; ASIC design; LAN systems, 
PSTN standards, ISDN standards, processor 
architectures, high-speed logic; 16-bit MPU 
design practices, programmable logic; digital 
modulation synchronization, adaptive signal 
processing, viterbi algorithm and MLSE, 
decision Feedback equalizer; convolutional 
code and linear block code, speech coding, 
echo cancellation, encryption; CAE techni¬ 
ques for digital hardware design using Men¬ 
tor Graphics, etc; data communications pro- 
tocols(CCin ■7, OSI, X.25 X.75, PAD. LjAPB, 
LAPD, Ethernet, ISDN, CCITT V series 
modem, group 3 fax); computer network 
management/administration (Apollo, Sun, 
Mentor Graphics, AppleTalk). BSEE/MSEE/ 
BSC E/BSCS or equivalent. Respond to Dept. 
EC. 


MECHANICAL: Electronic packaging; CAD. 
CV CADDS 4X; materials selection and 
geometric tolerances and dimensioning; ex¬ 
truded metal; injection molded plastics; life 
test procedures and factory introduction and 
support; plating materials and processes; 
structural analysis nnodeling; die casting and 
sheet metal stampings; thermal manage¬ 
ment. BSME/MSME or equivalent. Respond 
to Dept ME. 

SYSTEMS: Radio/cellular communication 
systems engineering; RF propagation predic¬ 
tion methods; PSTN traffic planning; 
telephone network, interconnection and 
telecommunication industry standards; 
microwave system design and equipment 
engineering; telephone switching sykems; 
software programming skills. BSEE/BSCE/ 
BSCS or equivalent. Respond to Dept. S. 
•Registered trademark of ATST 


Our breakthroughs 

are heard around the world. 


UPDATE 


Contributions to Update are welcome. Send news of public policy or professional issues and of industrial or university 
research to Steve Wilcox, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264, or to Editor-in-Chief 
Bruce D. Shriver, Vice President for Research, University of Southwestern Louisiana, Drawer 42370, Lafayette, LA, 70504. 


NSF asks for 14 percent hike in 1991 budget 


The National Science Foundation’s 
proposed budget for 1991 would increase 
the funding of computer-related activi¬ 
ties by almost 14 percent. 

The overall budget reflects a 14.4 per¬ 
cent increase over 1990 actual funding 
levels. The NSF budget for 1990 is $2.08 
billion. The proposed 1991 budget is 
$2.38 billion. 

An NSF statement said the budget fo¬ 
cuses on strengthening the research base, 
improving academic research equipment 
and facilities, developing human re¬ 
sources, broadening participation, and 
improving science and engineering edu¬ 
cation at all levels. 

NSF funding for computer and infor¬ 
mation science and engineering would 
rise 13.8 percent over actual 1990 fund¬ 
ing to $193.25 million. NSF breaks this 
area into smaller categories as follows: 

• Computer and computational re¬ 
search would get a 10.5 percent boost to 
almost $24.3 million. 

• Information robotics and intelligent 
systems would receive 14.5 percent more 
than in 1990, or $22.88 million total. 

• Microelectronic information pro¬ 
cessing systems would get $18.87 mil¬ 
lion, a 13.6 percent increase. 

• Advanced scientific computing was 
the only computer-related category 
slated for less funding. It would drop 0.4 
percent to $62.58 million under the pro¬ 
posed budget. 

• Networking and communications re¬ 
search and infrastructure would jump 41 
percent to $31.29 million. 

• Cross-disciplinary activities would 


benefit from a 22.4 percent increase to 
$24.03 million. 

• Science and Technology Centers 
would get a 41.9 percent hike to $9,320 
million. 

Overall, more than 70 percent of the 
1991 budget is slated for research and fa¬ 
cilities. NSF would roughly double its 
support — to $103 million — for global- 
change research, focusing on basic re¬ 
search in climate and hydraulic cycles, 
bioresponse to climate, land-margin eco¬ 
systems, and database management. The 
budget also proposes a project involving 
biochemists, geneticists, computer sci¬ 
entists, and several federal agencies in an 
effort to map and sequence a plant 
genome. 

Also, $463 million would go toward 
education and human resources activities 
($335 million and $128 million, respec¬ 
tively). The NSF’s primary goal in this 
category is to attract and keep students 
from underrepresented segments of the 
population. The NSF budget for special 
programs for minority institutions and 
for women, minority, and disabled stu¬ 
dents and investigators would jump 48.5 
percent to $94 million. [See the related 
story below.] 

Generally, precollege programs would 
get a 17.8 percent boost to $165 million, 
and undergraduate research and educa¬ 
tion programs would get $134 million, a 
48 percent increase over 1990. Several 
proposed programs would support multi¬ 
disciplinary training. Also, the Presiden¬ 
tial 'i^oung Investigators program would 
offer 200 more awards for a total of 950. 


Science in the US still a white man’s world 


Women, blacks, and Hispanics con¬ 
tinue to be underrepresented in science 
and engineering, according to a National 
Science Foundation study. 

Women and Minorities in Science and 
Engineering states that between 1978 
and 1988, the number of women in sci¬ 
ence and engineering increased 258 per¬ 
cent, while the number of men rose only 


87 percent. Even with that increase, how¬ 
ever, women represent only 16 percent of 
the US workforce in science and engi¬ 
neering, while they occupy 45 percent of 
US jobs overall. 

The study found that the problem is 
worse in engineering and some natural 
science fields than in the life or social sci¬ 
ences. 
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Other findings of the study include: 

• Women have entered the field rela¬ 
tively recently, so they are generally 
younger and have fewer years of profes¬ 
sional experience than men. About three- 
quarters of the men but only about two- 
fifths of the women have 10 years’ expe¬ 
rience. 

• Annual salaries for women in the 
field are about 75 percent those of men — 
or $29,900 versus $39,800. Men’s sala¬ 
ries exceed women’s in almost all science 
fields and at all levels of experience ex¬ 
cept in a few entry-level positions. 

• Blacks accounted for about 2.6 per¬ 
cent of employed scientists and engineers 
in 1988, up from 1.8 percent in 1978 but 
still lagging behind their representation 
in both the general workforce (10 per¬ 
cent) and in professional and related jobs 
(7 percent). About 5 percent of employed 


women scientists and engineers are black, 
compared with about 2 percent of the men. 

• Asians are better represented in sci¬ 
ence and engineering than in the general 
workforce, comprising about 5 percent of 
both women and men scientists and engi¬ 
neers, compared with about 2 percent in 
the general workforce. 

• In 1986, about 2 percent of the sci¬ 
ence and engineering workforce reported 
a physical disability. Of these, 23 percent 
reported an ambulatory disability, 22 
percent a visual condition, and 17 percent 
an auditory disability. 

Copies of the report are available from 
the Scientific and Technical Personnel 
Studies Group, Division of Science Re¬ 
source Studies, National Seience Foun¬ 
dation, 1800 G Street NW, Room L-611, 
Washington, DC 20550, phone (202) 
634-4664. Specify report NSF 90-301. 


New Zealand school claims programming title 


The University of Otago in New Zea¬ 
land beat out 23 other schools to claim 
first place in the Association of Comput¬ 
ing Machinery’s 14th annual Scholastic 
Programming Contest February 21 in 
Washington, DC. 

The University of Maryland and Stan¬ 
ford University took second and third 
place, respectively, in the contest, which 
gave the teams five hours to solve eight 
programming problems of varying diffi¬ 
culty. The goal was to solve as many prob¬ 
lems as quickly as possible and with the 
fewest number of tries. 

The competition began with 12 re¬ 
gional competitions last autumn involv¬ 
ing 459 teams of no more than four com¬ 
puter-science students each. The teams 
represented more than 354 schools in the 
United States, Europe, and the Pacific 
Rim. The final competition featured two 
teams from each region. 

The problems featured in this year’s 
competition were 

• Rare order. Given the index of a book 
written in a fictional language that uses 
the same letters as English, write a pro¬ 
gram to determine the language’s charac¬ 
ter order. 

• Squares. A children’s game board has 
a 4x4 array of dots, which the children 
connect to form squares of different 
sizes. Given partially filled-in game 
boards, write a program to count all 
squares of all sizes formed in the game. 

• Repeating decimals. Given several 
fractions, write a program to determine 
the “repeating cycle” and “cycle length” 
for the decimal equivalents. For example. 


the decimal expression 0.769 has a re¬ 
peating cycle of 769 and a cycle length 
of 3. 

• Running lights visibility calculator. 
Write a program to determine if ships will 
collide based on the positions of their run¬ 
ning lights at three-minute intervals. 

• Robot crash. Write a program to de¬ 
termine if and where on their paths two 
robots will collide. 

• Getting there. Given information on 
airline schedules, stopovers, and prices, 
write a program to determine the best 
routes for passengers who want to mini¬ 
mize either cost or travel time. 

• Meals on Wheels routing system. 
Meals on Wheels provides hot meals to 
homebound senior citizens. The number 
of drivers tmd customers varies daily. 
Write a program to equally allocate cus¬ 
tomers among drivers based on the num¬ 
ber of drivers, the number of customers, 
and the locations of the customers and the 
headquarters. 

• Golf tour prize money. Write a pro¬ 
gram to determine how to allocate the to¬ 
tal prize money for a professional golf 
tournament. 

Filling out the top 10 finishers were 
Harvard University, Eindhoven Techni¬ 
cal University in the Netherlands, the 
University of Wisconsin at Madison, 
Leiden University in the Netherlands, the 
University of Southwestern Louisiana, 
Duke University, and Virginia Tech. 

A total of $25,000 in scholarships was 
awarded to the top six schools, and the top 
four schools also received AT&T work¬ 
group system computers. 


News briefs 

McGroddy looks to the future. 

The 1990’s will see the introduction of 
100-Mbit memory chips, and 100- 
MIPS workstations are not far away, 
predicted James McGroddy, director 
of IBM’s T.J. Watson Research Cen¬ 
ter, at the annual ACM Computer Sci¬ 
ence Conference, held February 20- 
22 in Washington, DC. 

McGroddy said the industry should 
remain intensely competitive because 
that competition leads to technologi¬ 
cal advances. But, noting that the cen¬ 
ters for processing technology have 
moved to the Far East, he also called 
for more cooperation in four areas: 

• Creating new semiconductor and 
superconducting technologies. “Pre¬ 
paring this technology is expensive, 
long-range, and risky, [but] by work¬ 
ing together, multiple approaches can 
be pursued, thereby reducing the 
risk,” McGroddy said. 

• Improving DRAM production. 
Citing the demise of the US Memories 
chip consortium, McGroddy called 
for cooperation to “create neutral and 
relatively secure sources of DRAMs.” 

• Reducing the cost of capital. Cit¬ 
ing the US National Advisory Com¬ 
mittee on Semiconductors, McGroddy 
argued that chip production is capital- 
intensive, so the industry needs 
mechanisms for low-cost financing to 
remain competitive. —Paul Oman 


Consortium launches Future- 
bus+ architecture. A number of IC 
and computer makers have announced 
the launch of the VME Futurebus+ Ex¬ 
tended Architecture. The architecture 
expands the 32-bit VMEbus to 64 bits 
and includes Futurebus+ high-speed 
interconnection and an open software 
standard specification. Participants in 
the consortium include Digital Equip¬ 
ment Corporation, Motorola, National 
Semiconductor, Sun Microsystems, 
and Unisys. 

Also, a $30 million contract to de¬ 
velop engineering workstations based 
on the architecture was announced in 
Europe. The contract is funded by the 
European Economic Community un¬ 
der the ESPRIT project. 

The architecture was designed as a 
collaborative effort by several inter¬ 
national manufacturers and the US 
Navy under the auspices of the 
VMEbus International Trade Asso¬ 
ciation and the Institute of Electrical 
and Electronics Engineers. 
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CALL FOR PAPERS 

IEEE Conference on 

Neural Information Processing Systems 
-Natural and Synthetic- 

Monday, November 26 - Thursday, November 29,1990 
Denver, Colorado 

This is the fourth meeting of an inter-disciplinary conference which brings together neuroscientists, 
engineers, computer scientists, cognitive scientists, physicists, and mathematicians interested in all 
aspects of neural processing and computation. Two days of focused workshops will follow at a nearby 
ski area (Nov 30-Dec 1). Major categories and examples of subcategories for paper submissions are the 
following; 

Neuroscience: Neurobiological models of development, cellular information processing, synaptic function, 
learning and memory. Studies and analyses of neurobiological systems. 

Implementation and Simulation: Hardware implementation of neural nets. VLSI, Optical Computing, 
and practical issues for simulations and simulation tools. 

Algorithms and Architectures: Description and experimental evaluation of new net architectures or 
learning algorithms; data representations, static and dynamic nets, modularity, rapid training, learning pattern 
sequences, implementing conventional algorithms. 

Theory: Theoretical analysis of: learning, algorithms, generalization, complexity, scaling, capability, 
stability, dynamics, fault tolerance, sensitivity, relationship to conventional algorithms. 

Cognitive Science & AI: Cognitive models or simulations of natural language understanding, problem 
solving, language acquisition, reasoning, skill acquisition, perception, motor control, categorization, or 
concept formation. 

Applications: Neural Networks applied to signal processing, speech, vision, character recognition, motor 
control, robotics, adaptive systems tasks. 

Technical Program: Plenary, contributed and poster sessions will be held. There will be no parallel 
sessions. The full text of presented papers will be published. Submission Procedures: Original research 
contributions are solicited, and will be carefully refereed. Authors must submit six copies of both a 
1000-word (or less) summary and six copies of a separate single-page 50-100 word abstract clearly 
stating their results by May 17, 1990. At the bottom of each abstract page and on the first summary page 
indicate preference for oral or poster presentation and specify one of the above six broad categories and, if 
appropriate, sub-categories (For example: POSTER-Applications: Speech, ORAL-Implementation: 
Analog VLSI). Include addresses of all authors at the front of the summary and the abstract and to which 
author correspondence should be addressed. Submissions will not be considered that lack category 
information, separate abstract sheets, the required six copies, author addresses or are late. 


Mail Submissions To: Mail Requests For Registration Material To: 

John Moody Kathie Hibbard 

NIPS*90 Submissions NIPS*90 Local Committee 

Department of Computer Science Engineering Center 

Yale University University of Colorado 

P.O.Box 2158 Yale Station Campus Box 425 

New Haven, Conn. 06520 Boulder, CO 80309-0425 


Organizing Committee: 

General Chair: Richard Lippmann, MIT Lincoln Labs; Program Chair: John Moody, Yale; Neurobiology Co-Chair: 
Terry Sejnowski, Salk; Theory Co-Chair: Gerry Tesauro, IBM; Implementation Co-Chair: Josh Alspector, Bellcore; 
Cognitive Science and AI Co-Chair: Stephen Hanson, Siemens; Architectures Co-Chair; Yann Le Cun, ATT Bell 
Labs; Applications Co-Chair: Lee Giles, NEC; Workshop Chair Alex Waibel, CMU; Workshop Local 
Arrangements, Howard Wachtel, U. Colorado; Local Arrangements, Kathie Hibbard, U. Colorado; Publicity: 
Stephen Hanson, Siemens; Publications: David Touretzky, CMU; Neurosciences Liaison: James Bower, Caltech; 
IEEE Liaison: Edward Posner, Caltech; APS Liaison: Larry Jackel, ATT Bell Labs; Treasurer: Kristina Johnson, U. 
Colorado; 

DEADLINE FOR SUMMARIES & ABSTRACTS IS MAY 17,1990 





^"SSNEWS 


Editor: Guylaine M. Pollock, Sandia National Laboratories, Division 1424, P.O. Box 5800, Albuquerque, NM 87185; phone, (505) 846-0040; Internet, gmpollo@sandia.oov 


Editor-in-chief nominations sought for society publications 


Nominations of qualified candidates 
are invited for editor-in-chief positions 
on seven IEEE Computer Society publi¬ 
cations. The publications, along with the 
chair of the respective search committee. 


Computer, Sushil Jajodia, George 
Mason University, ISSE Dept., 
Fairfax, VA 22030-4444; 

IEEE Software, Norm Schneide- 
wind. Naval Postgraduate School, 
Code 54SS, Dept. RSA/CS, Mon¬ 
terey, CA 93940; 

IEEE Computer Graphics and Appli¬ 
cations, Carl Machover, Machover 
Associates Corp., 199 Main St., 
White Plains, NY 10601; 

IEEE Micro, James Farrell, VLSI 
Technology Inc., 8375 South River 
Pkwy., Tempe, AZ 85284; 

IEEE Transactions on Computers, 


The National Security Industry Asso¬ 
ciation Software Committee presented 
the 1989 Grace Murray Hopper Award to 
Barry W. Boehm, director of DARPA’s 
Information Science and Technology Of¬ 
fice (ISTO), at the committee’s general 
membership meeting in Fort Worth, 
Texas, February 6. The award recognizes 
Boehm’s “deep interest, unusual creative 
ability and demonstrated competence, 
his many outstanding contributions, and 
his leadership in the field of software 
used for national security.” 

In his current position with DARPA- 
ISTO, Boehm directs the US govern¬ 
ment’s largest computer-communica¬ 
tions research organization. DARPA- 
ISTO’s Software Technology for Adapt¬ 
able, Reliable Systems (STARS) pro¬ 
gram has been developing a national soft¬ 
ware repository to expedite software 
reuse, and a number of enabling technol¬ 
ogy components to support development 
of a set of software engineering environ¬ 
ments (SEEs). Under Boehm’s leader¬ 
ship, STARS has recently been reori- 


Harold Stone, IBM T.J. Watson Re¬ 
search Center, Route 134, PO Box 
218 (Room H1D62), Yorktown 
Heights, NY 10598; and 

• IEEE Transactions on Pattern Analy¬ 
sis and Machine Intelligence and 
IEEE Transactions on Knowledge 
and Data Engineering, Bruce Berra, 
Syracuse University, Dept. ECE, 111 
Link Hall, Syracuse, NY 13244. 

The call for nominations was an¬ 
nounced by Sallie Sheppard, Computer 
Society vice president of publications, at 
the March 2 meeting of the society’s 
Board of Governors. 

The editor-in-chief is responsible for 
targeting the publication’s coverage. 
Therefore, each nominee must have dem¬ 
onstrated innovative leadership in his or 
her technical field, must have experience 
in publishing in this field, and must be na- 


ented to focus on developing these SEEs 
as proof-tested, Ada-supportive, com¬ 
mercially maintained products with stan¬ 
dardized open interfaces to promote ser¬ 
vice and industry enhancements and to 
stimulate a robust. Department of De¬ 
fense-responsive commercial software 
tools industry. 

At TRW, Inc., between 1973 and 1989, 
Boehm’s contributions to the software 
field included advances in software mtm- 
agement involving the 1970s waterfall 
model, the 1980s spiral model, software 
risk management, and Theory W. A mem¬ 
ber of the IEEE Computer Society, 

Boehm is an author whose book contribu¬ 
tions include Characteristics of Software 
Quality (1978), Software Engineering 
Economics (1981), and the 1989 Com¬ 
puter Society Press tutorial volume Soft¬ 
ware Risk Management (Order No. 1906, 
book; Order No. 1906AV, videotape). 

Boehm is the first person to receive the 
award since its initial presentation to 
Admiral Grace Murray Hopper in 1988. 


tionally recognized. Nominations may be 
sent directly to the chair of the search 
committee or to Sallie Sheppard, Vice 
President of Publications, Texas A&M 
University, Associate Provost for Under¬ 
graduate Studies, 104 Academic Build¬ 
ing, College Station, TX 77843-4233. 

Nominations will be screened by the 
search committees, and their recommen¬ 
dations will be presented to the Board of 
Governors at its June 8 meeting. 


Subcommittee on 
Software Reliability 
Engineering chartered 

Because reliability of software sys¬ 
tems and systems containing embedded 
software is of increasing concern to in¬ 
dustry and government, the IEEE Com¬ 
puter Society’s Technical Committee on 
Software Engineering has chartered a 
Subcommittee on Software Reliability 
Engineering. The subcommittee’s initial 
meeting is scheduled for April 12 and 13 
at NASA headquarters in Washington, 
DC. 

The subcommittee will deal with the 
application of current techniques for im¬ 
proving, measuring, and managing soft¬ 
ware reliability. The focus will be on 
quantitative assessment of these tech¬ 
niques, particularly in regard to recent 
industrial or government applications. 

Two meetings are planned for 1990. 
Technical talks on current applications 
and work in progress will be given, and 
further subcommittees may be formed to 
investigate specified technical ques¬ 
tions. The subcommittee will publish a 
newsletter after each meeting. 

A. Frank Ackerman, a consultant to 
AT&T Bell Laboratories, Michael Lyu of 
the Jet Propulsion Laboratory, and Val¬ 
eria Nereo of Hewlett-Packard are serv¬ 
ing as an ad hoc organizing committee. 
Interested parties should contact Acker¬ 
man at AT&T Bell Laboratories, Room 
6E110, Whippany Rd., Whippany, NJ 
07981, phone (201) 386-3377; Usenet, 
attlwhuxrlafa. 


Barry Boehm receives 1989 
Grace Murray Hopper Award 
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Operating Systems TC enjoys growth and new activities 

Luis-Felipe Cabrera, Chair, Technical Committee on Operating Systems 


The IEEE Computer Society’s Techni¬ 
cal Committee on Operating Systems has 
a diverse set of ongoing activities to 
cover the different aspects of operating 
systems. We publish a newsletter, spon¬ 
sor a vast amount of standards work, or¬ 
ganize workshops, and collaborate on 
workshops and conferences with other 
professional organizations. 

Publications. The TCOS Newsletter, 
our regular member publication, is the 
main communication channel for TC 
members. We occasionally devote issues 
to special topics, for example, in 1989 an 
issue on process migration and another 
with selected papers from the Second 
IEEE Workshop on Workstation Operat¬ 
ing Systems. TCOS members contribute 
regularly to IEEE Transactions on Com¬ 
puters, IEEE Software, and Computer. 
TCOS Past-Chair Joseph Boykin is guest 
editing the May 1990 Computer on oper¬ 
ating systems. 

Standards. Under the overall leader¬ 
ship of Jim Isaak, efforts on Posix and 
windowing environments will continue, 
with TCOS retaining a central role in 
these standards activities. All work in the 
1003.x committees is performed under 


our sponsorship. Standards work is mov¬ 
ing into areas of computing systems out¬ 
side the kernel, resulting in several new 
standards efforts, for example, in win¬ 
dow subsystems. We expect to lead the 
way in these expanding areas, just as we 
did in the Posix effort. 

Workshops and conferences. During 
1989 the TC organized and sponsored a 
workshop on workstation operating sys¬ 
tems at Asilomar in Pacific Grove, Cali¬ 
fornia. Copies of the workshop proceed¬ 
ings can be obtained from the Computer 
Society Press, 10662 Los Vaqueros Cir., 
Los Alamitos, CA 90720-1264, Order 
No. 2003. The number of position state¬ 
ments received and the requests for atten¬ 
dance demonstrated the vitality of re¬ 
search in the field. 

This year TCOS is sponsoring a work¬ 
shop on management of replicated data. 
Interested parties should contact Jehan- 
Francois Paris, Computer Science De¬ 
partment, University of Houston, Hous¬ 
ton, TX 77204-3475, by the April 16 
deadline. 

The TC also has worked with other so¬ 
cieties on conferences and workshops. 
We are cooperating with ACM’s Special 


Interest Group for Computer and Human 
Interaction (SIGCHI) for CHI 90, the 
Conference on Human Factors in Com¬ 
puting Systems. We joined with Usenix 
for the Workshop on Experiences with 
Building Distributed (and Multiproces¬ 
sor) Systems, and with ACM for 
ASPLOS-III, the Conference on Archi¬ 
tectural Support for Programming Lan¬ 
guages and Operating Systems. 

Steady growth. TCOS has been grow¬ 
ing steadily, with more than 200 people 
joining during 1989. We welcome this 
growth and expect it to foster additional 
activities through voluntary member par¬ 
ticipation. Currently we are looking for 
people who would like to contribute 
newsletter articles, act as guest editor of 
the newsletter, or help organize seminars, 
workshops, and conferences. 

In 1990 we plan four issues of the news¬ 
letter and initial tutorial activities. 

Further information about TCOS ac¬ 
tivities is available by contacting Luis- 
Felipe Cabrera, TCOS Chair, IBM Alma- 
den Research Center, Mail Code K55/ 
803, 650 Harry Rd., San Jose, CA 95120- 
6099, Internet cabrera@ibm.com, phone 
(408) 927-1838. 


Introducing TurboCASE™, the fastest, 
most integrated Macintosh CASE tool. 


StructSoft, Inc., the developer of one of the top selling 
PC CASE tools, now marketed as Teamwork/PCS A™ 
by Cadre Technologies, Inc., is proudly announcing 
a second generation CASE tool, TurboCASE, for the 
Apple Macintosh. 


TurboCASE is an integrated, multi-window, multi¬ 
methodology supporting CASE tool. It is extremely 
easy to learn and use. It supports Structured Analy¬ 
sis with or without the Real-Time extension. It will 
also support Data Modeling, Structured Design and 
Object Oriented Analysis and Design in the future. 


TurboCASE generates ASCII information exchange 
formats which can be used to link with Teamwork and 
Iconix' PowerTool™ 


A demo diskette is available for $15.00. 


StructSoft, Inc. 5416156th Ave. SE, Bellevue, WA 98006. Tel: 206-644-9834 Fax: 206-644-7714 

Trademarks; TurboCASE : StructSoft, Inc.; Teamwork, Teamwork/PCSA : Cadre Technologies, Inc.; PowerTool: Iconix. 



Reader Service Number 8 



















































CALL FOR PAPERS 




Tenth Annual IEEE 



1ICNTERNATIONAL 
■Ihoenix 

CONFERENCE on 
COMPUTERS and 
COMMUNICATIONS 


Sponsored by: 

INSTITUTE OF ELECTRICAL AND 
ELECTRONIC ENGINEERS 
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In cooperation with: 

THE IEEE COMPUTER SOCIETY, 
THE UNIVERSITY OF ARIZONA, 

ARIZONA STATE UNIVERSITY 


CONFERENCE CHAIRMAN: 

Dr. Oris Friesen 
Bull HN 

P.O. Box 8000, MS A93 
Phoenix, AZ 85066 
(602) 862-5200 
e-mail: Friesen@system-m.phx. 


IMPORTANT DATES: 

Submission Deadlines. 

For papers, special sessions, and 
tutorials: 

14 July 1990 
For exhibits: 

1 September 1990 

Acceptance notifications. 

For papers: 

20 September 1990 

For special sessions (provisional) 

and tutorials: 

15 August 1990 

Camera ready version of papers 
due 1 December 1990 

Conference Dates 
27-30 March 1991 


March 27-30,1991 

Scottsdale, Arizona 

This international conference provides a forum for the presentation and exchange of 
current work in the field of synergism of computers and communications, and their 
applications areas. We are particularly soliciting industrial, business, and government 
participation as well as the active involvement of the academic community. We know 
it is vital that there be a dialogue between practitioners and researchers. Thus, in 
addition to research contributions, we look forward to reports detailing experiments, 
evaluation, problems, and opportunities associated with design, implementation, and 
operation. Such reports will be given special consideration. 

Submitted manuscript must: be no longer than 5000 words, be typed double-spaced, 
and include an abstract of approximately 300 words. Long papers and reports will not 
be considered. Authors should obtain company and government clearances prior to 
submission of the papers. 

Please submit five copies of complete paper and abstract by 14 July 1990 to: 

James A. Weeldreyer, Program Chairman 
Honeywell, Incorfxtrated 
Industrial Automation Systems Division, MS 2E5 
16404 North Black Canyon Highway 
Phoenix, Arizona 85023 
(602) 863-5983 

e-mail: jw-ipccc@enuxha.eas.asu.edu 

All papers submitted will be refereed by the Program Committee. They will be judged 
with respect to their quality, originality, and relevance. Authors will be notified of 
acceptance/rejection shortly after 20 September 1990. Accepted papers will be pub¬ 
lished in the IPCCC Proceedings. 

SPECIAL SESSIONS 

We solicit proposals for special topics and panel sessions. Each proposal should 
include subject, justification, and names of possible participants. Proposals should be 
sent to the Program Chairman by 14 July 1990. Proposers will be notified of provisional 
acceptance shortly after 15 August 1990. 

TUTORIALS 

Proposals for one-day tutorials related to the suggested topics are desired. Please 
contact the Tutorials Chairman for tutorial proposal submission guidelines. Proposals 
should be sent by 14 July 1990 to: 

Dr. Robert R. Seban, Tutorials Chairman 
Computer Science and Engineering Department 
Arizona State University Tempe, Arizona 85287 
(602) 965-4174 

e-mail: seban@asuvax.eas.asu.edu 

EXHIBITS 

Exhibits of commercial products and demonstrable prototypes related to the suggested 
topics are solicited. Please contact the Exhibits Chairman for proposal submission 
guidelines. Proposals should be sent by 1 September 1990 to: 

Dr. Tom Howell, Exhibits Chairman 
Bull HN 

P.O. Box 8000, MS ZW 
Phoenix, Arizona 85066 
(602) 862-4486 


SUGGESTED TOPICS: 

Computer Technology 

• Parallel and Distributed 
Computing 

• Fault Tolerance and 
Reliability 

• Neural Network Computing 

• Distributed Database Systems 

• Optical Disk Storage 

• VLSIAfHSIC Developments 

• Advanced Architectures 

Communications Technology 

• Fiber Optics 

• Satellite^errestrial Systems 

• Communications Theory 

• Spread Spectrum 

Software Systems 

• Specification Methodologies 

• Development Environments 

• Object-Oriented Systems 

• Real-Time Systems 

• Performance Measurement and 
Evaluation 

• Graphics and Scientific 
Visualization 

• Distributed Operating Systems 

Networking Systems 

• OSI Networks and Inter¬ 
operability 

• Fault Tolerant Networks 

• Local and Wide Area Networks 

• Network Management, 

Control, and Security 

• ISDN Systems 

• Value Added Networking 

Al/Expert Systems 

• Expert System Design and 
Applications 

• Non-traditional Languages 

• Distributed Al Systems 

• Intelligent Databases 

Applications 

• Medical Information Systems 

• Process Control 

• CAD/CAE/CAM 

• Robotics and Computer Vision 

• Multi-Media Databases 










PRODUa REVIEWS 


Editor: Richard Eckhouse, UMASS-Boston, Harbor Campus, Boston, MA 02125, Compmail+, r.eckhouse; Bitnet, eckhouse@umbsky; CompuServe, 70516,556 


Breaking the DOS 640-Kbyte barrier 


Daniel McAuliffe 

While the argument proceeds over 
which operating system, Unix or OS/2, 
will dominate the personal computer 
market, applications designed for the 
DOS environment continue to pour out 
of developers’ workshops. Newer prod¬ 
ucts, such as Lotus 1-2-3 Version 3 and 
dBase IV, offer a host of sophisticated 
features that invariably require more 
memory. Yet DOS, with its 640-Kbyte 
memory limitation, remains immutable, 
forcing developers to reach ever deeper 
into their bag of programming tricks to 
force their applications to fit. 

OS/2 does not offer a clear solution to 
the problem. Big and often slow, it not 
only fails to utilize the full power of the 
Intel 386 processor, it requires so much 
expensive memory as to almost preclude 
users with limited resources. Unix, on 
the other hand, requires users to become 
familiar with syntactically obscure com¬ 
mands and an environment originally de¬ 
signed for software developers, not end 
users of applications. It also lacks the 
wealth of applications software many us¬ 
ers have become accustomed to, nor does 
it yet offer a graphical interface in the 
same class as Microsoft Windows or 
Presentation Manager. 

Fortunately, an alternative exists. 

Many popular PC applications software 
packages currently use it, such as Lotus 
1-2-3, AutoCAD, Cadkey 3.0 Plus, Para¬ 
dox 386, and Professional Oracle. The 
solution, incorporated in packages 
known as DOS extenders, allows appli¬ 
cations developed for IBM-compatible 
286 or 386 machines to take advantage 
of at least 16 Mbytes and in some cases 
as much as 4 Gbytes of memory. This 
review examines three of the DOS exten¬ 
ders currently available to software de¬ 
velopers and looks at some of their ad¬ 
vantages and disadvantages. 


Theory of operation 

Most DOS personal computers use 
286/386 processors only for increased 


speed. Their applications still operate in 
real mode and do not take advantage of 
the full protected-mode environment and 
extended address space offered by both 
processors. In protected mode, the 286 
can address a full 16 Mbytes of physical 
memory, while the 386 permits access to 
a whopping 4 Gbytes of memory. A DOS 
extender will allow your current applica¬ 
tions or new programs access to this ex¬ 
tended memory with very little effort on 
your part. In fact, in some cases you can 
continue to use your favorite compiler 
and not recompile any of your programs. 

One of the major differences between 
real-mode and protected-mode program¬ 
ming is the use of segment registers. In 
real mode, segment registers point to the 
actual location of a physical memory 
segment or paragraph. This value, to¬ 
gether with the offset into the segment, is 
used to calculate the linear memory ad¬ 
dress. In protected mode, segment regis¬ 
ters contain segment selectors that act as 
indices into either a global descriptor 
table (GDT) or a local descriptor table 
(LDT^ The entries in the descriptor 
table, together with the segment offset, 
provide the processor with the informa¬ 
tion necessary to map a logical address 
into a linear address. This information 
consists of the base address of the seg¬ 
ment, the size of the segment, the content 
(code or data), the privilege level of the 
code allowed to access the segment, and 
the segment read/write/execute access 
type. The processor uses the information 
in the descriptor table to implement the 
access and protection mechanisms for 
protected mode. Descriptor tables are 
created and maintained by the DOS 
extender, which also responds to any 
protection violations generated by the 
processor and handles address transla¬ 
tion between real- and protected-mode 
environments. 

A DOS extender acts as a shell sur¬ 
rounding your application program. 

When started, it loads your application 
into extended memory, builds the re¬ 
quired selector tables for the memory 
addressing scheme of the 286 or 386, 


then switches the processor into pro¬ 
tected mode to execute your program. 
When your application requires any of 
the services provided by DOS, the exten¬ 
der switches the processor into real 
mode, performs any necessary address 
translation if you are accessing conven¬ 
tional memory, moves any required data 
from extended memory to conventional 
memory, and calls upon the DOS serv¬ 
ices to perform the requested function. 
This can include any of the BIOS serv¬ 
ices provided by DOS, including file and 
device I/O. When DOS has completed its 
operations, the extender moves any re¬ 
quired data up to extended memory and 
switches the processor back to protected 
mode. 

Switching from protected mode to real 
mode operates the same for both 286 and 
386 processors. However, the 286 does 
not provide the facility for easily switch¬ 
ing from real mode back to protected 
mode. On the 286, you must save the 
processor state and then reset the proces¬ 
sor to return to protected mode. This 
process can take anywhere from several 
hundred microseconds to more than a 
millisecond and can result in loss of data 
if fast hardware interrupts are active dur¬ 
ing the processor transition phase. 

If you program in a high-level lan¬ 
guage such as C or Fortran, you will 
probably notice little difference between 
real and protected mode if your programs 
follow normal conventions and are “well 
behaved.” In assembly language pro¬ 
gramming, however, you must avoid in¬ 
structions that might cause a processor 
exception when running in protected 
mode. A processor exception can be 
caused by any of the following actions: 

(1) Self-modifying code. This is poor 
programming practice no matter what 
mode you run in, but is absolutely disal¬ 
lowed in protected mode because of the 
strong separation of code and data. It 
simply will not work. 

(2) Arithmetic on segment addresses. 
In protected mode, segment registers 
contain selectors, not physical addresses 
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as in real mode. Any arithmetic opera¬ 
tion on the contents of the segment regis¬ 
ter has no meaning and will result in an 
exception. 

(3) Attempting to execute code stored 
in the data area of your program. Again, 
because of the strong separation between 
code and data in protected mode, this 
will result in an exception. 

You can easily avoid each of these 
protected-mode violations if you take 
care to do so. Generally, they are prac¬ 
tices you should avoid anyway, even 
when programming for a real-mode 
environment. 


Rational Systems 
DOS/ 16 M 

DOS/16M, from Rational Systems, 
works with either the 286 or 386 proces¬ 
sor. The kernel contains code for deter¬ 
mining the type of processor and takes 
advantage of the special features of the 
386 for more efficient switching between 
real- and protected-mode environments. 

It does not, however, take advantage of 
the paging or linear address capabilities 
of the 386, thus limiting the accessible 
memory to 16 Mbytes. 

DOS/16M has the smallest kernel of 
all the extenders reviewed here, occupy¬ 
ing approximately 24 Kbytes of conven¬ 
tional DOS memory. This makes it ideal 
for building protected-mode terminate- 
and-stay-resident (TSR) applications. 

The main body of the TSR can reside in 
extended memory, with only a small stub 
remaining resident in conventional DOS 
memory. When the TSR becomes active, 
it switches to protected mode and in¬ 
vokes the code in extended memory. Af¬ 
ter completing its task, the processor is 
switched back into real mode. The DOS/ 
16M manual contains examples of how 
to write protected-mode TSRs, and the 
distribution disks include a number of 
additional examples. 

You do not need to recompile your 
programs to produce a protected-mode 
version if you use one of the many com¬ 
pilers supported by DOS/16M. However, 
be sure to generate code specifically for 
the 286 processor and compile your mod¬ 
ules with stack checking disabled — the 
286/386 hardware will perform this func¬ 
tion. I used the Microsoft C 5.1 compiler 
with the G2 and Gs options for this pur¬ 
pose. If you plan to use the DOS/16M 
protected-mode debugger, you should 
also force the compiler to include source 
code information in the object modules. 
In the case of Microsoft C 5.1, this 
means selecting the Zd switch to produce 
CodeView information. 


Once you are satisfied with your com¬ 
piled code, you must link your modules 
with compiler-specific modules supplied 
on the distribution disks. Using the Mi¬ 
crosoft linker requires a minimum of 
three separate DOS/16M modules and 
might require additional support mod¬ 
ules. For instance, if you use the float¬ 
ing-point emulation library, you will 
need to include the DOS/16M emulator 
module. You should also include the 
CodeView debugging information in the 
.exe file if you plan to use the DOS/16M 
protected-mode debugger. Because the 
linking process produces an .exe file 
with protected-mode instructions, the 
program will fail if you attempt to exe¬ 
cute it in real mode. You must perform 
an additional step to convert the program 
so that it will run in a protected-mode 
environment. The Makepm program is 
included just for this purpose. It takes the 
.exe file, and the .map file if present, and 
produces a protected-mode program. It 
generates two files; an .exp file that is a 
protected-mode version of the executable 
file and a .dbg file that contains symbolic 
information for the debugger. 

At this point you can load and execute 
your program with the Instant-D pro¬ 
tected-mode debugger. This window-ori¬ 
ented debugger has five separate view¬ 
ports: the code window, the dialogue 
window, the data window, the registers 
window, and the stack window. The lay¬ 
out of the screen, the use of the function 
keys, and the individual commands 
closely resemble the Microsoft Code- 
view debugger, making it relatively easy 
to jump back and forth between the two 
debuggers. 

Instant D is smart enough to know 
when it is running on a 386 and will use 
the processor debugging registers when 
it can. It is a full source-level debugger, 
allowing you to view your code at the 
assembly level, at the mixed source and 
assembly level, or with only the source 
code in the code window. You can 
switch between the different modes of 
representation simply by toggling the F3 
function key. 

Once your program executes success¬ 
fully with the debugger, you can build a 
stand-alone version that can be executed 
directly from the DOS command line. 
The Splice utility binds the .exp file and 
the loader.exe file supplied by Rational 
Systems. The Loader file contains the 
same startup and runtime support faci¬ 
lities as Instant-D, but without the de¬ 
bugger. 

I tested DOS/16M with two separate 
programs. The first dealt with some very 
large data files and performed a number 
of floating-point-intensive matrix inver¬ 
sions. All of the code was written in C, 
with the exception of some assembly 


routines to access network drives. It took 
less than one hour to produce a stand¬ 
alone protected-mode version of the ex¬ 
ecutable file. In fact, I was able to per¬ 
form the entire process with a simple 
batch file. I also did some crude esti¬ 
mates of the runtime differences between 
the real-mode version and the protected- 
mode version. I noticed no appreciable 
differences. 

The second test program, which used a 
commercial windowing library, proved 
more troublesome. The program in¬ 
cluded a number of ill-behaved assembly 
language routines (in terms of their reg¬ 
ister usage). The most glaring violation 
was the practice of storing data in the 
code segment. The Instant-D debugger 
quickly isolated each of these problems. 

In both test cases, I was impressed by 
how easy DOS/16M and the Instant-D 
debugger were to use. However, prob¬ 
lems encountered with the second test 
case did point out one area of concern: 
incompatibilities in your favorite com¬ 
mercial library packages, which might 
force you to work closely with their 
manufacturers to correct the problem. 

The DOS/16M package includes a li¬ 
brary of functions for the protected-mode 
environment. The functions address three 
main concerns for protected-mode pro¬ 
gramming: interrupt handling, memory 
management, and process management. 

The interrupt-handling functions allow 
you to manage interrupts in either real or 
protected mode and to pass interrupts re¬ 
ceived in real mode up to protected 
mode, or to pass down interrupts re¬ 
ceived in protected mode to real mode. 
You must take great care in switching 
between modes to handle an interrupt, 
since the potentially long time to switch 
from protected mode to real mode on a 
286 processor can restrict the number of 
interrupts you can successfully manage. 
Some AT-compatible machines require 
as much as 300 microseconds to switch 
from one mode to another and back 
again. The DOS/16M manual discusses 
this problem in some detail and offers 
suggestions for controlling the situation. 
One solution offered by Rational Sys¬ 
tems is to ensure that the interrupt is 
serviced in the mode in which it is re¬ 
ceived. You can do this by installing 
both a real- and a protected-mode inter¬ 
rupt handler, thus preventing any mode 
switching. The DOS/16M manual con¬ 
tains a number of examples of code deal¬ 
ing with proper handling of interrupts. 

The memory-management functions 
give you control over the allocation of 
memory from either conventional DOS 
memory or the extended memory pool. 
You are free to choose from which pool 
you want the memory allocated and to 
dynamically transfer data between the 
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two types of memory. Functions are also 
available for converting addresses be¬ 
tween real and protected mode. 

The process management functions 
provide the tools for switching between 
real and protected mode, manipulating 
the CPU stack, and activating interrupts. 
The manual provides examples for each 
of the functions in the library, and the 
distribution disks include additional 
programs showing you how to use the 
functions. 

The DOS/16M distribution package 
contains a number of handy utilities in 
the event you run into difficulties. The 
Exambios program examines the BIOS 
for compatibility with protected mode 
and creates an information file you can 
send to Rational Systems for investiga¬ 
tion. The Pminfo program measures the 
performance of your extended memory 
and protected mode. It measures mem¬ 
ory performance using an 8-MHz IBM 
PC AT system as a baseline and also es¬ 
timates the switch rate between real 
mode and protected mode. 

Rational Systems DOS/16M is in¬ 
tended as an OEM product and is priced 
accordingly. An Initial Development Li¬ 
cense (IDL) costs $5,000. The price of 
DOS/16M includes the right to distribute 
up to 200 copies of a single protected- 
mode version of one program. A Devel¬ 
opment Site License for 10 or more pro¬ 
grammers costs $15,000, assuming you 
have purchased an IDL. This price is 
considerably higher than the price of ei¬ 
ther of the other DOS extenders. How¬ 
ever, Rational Systems feels that it has 
stronger support services than the other 
manufacturers. Also, the company con¬ 
stantly updates DOS/16M. According to 
a company representative, it’s not un¬ 
usual for the company to offer upgrades 
as often as twice weekly. 

Rational Systems can be reached at PO 
Box 480, Natick, MA 01760, phone 
(508) 653-6006. 
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Eclipse OS/286 and OS/ 
386 DOS extenders 

Eclipse Computer Solutions (formerly 
AI Architects) provides two separate 
DOS extender packages. OS/286 is a 16- 
bit version that runs on either a 286 or 
386 machine; OS/386 specifically targets 
the 386 processor. Each development kit 
is priced at $495, with separate runtime 
license fees based on the size of the ex¬ 
isting installed base of the application 
being ported to the extender. Fees range 
from a low of $10 if you have fewer than 
2,500 copies to a high of $15,000 if the 


Once the appropriate files 
are copied to your hard 
disk, the installation 
procedure will run a 
program called Tune, 
which attempts to 
optimize the performance 
of the OS/x86 kernel for 
your machine. 


installed base is more than 10,000 
copies. 

The OS/x86 developer’s kit comes on 
three high-density 1.2-Mbyte or 1.44- 
Mbyte diskettes: a single system disk 
and two demo disks. A batch file for 
automating the installation process is in¬ 
cluded on the system disk. It allows you 
to place the distribution files in any di¬ 
rectory on your hard disk. Once the ap¬ 
propriate files are copied to your hard 
disk, the installation procedure will run a 
program called Tune, which attempts to 
optimize the performance of the OS/x86 
kernel for your machine. It first searches 
an internal database to see if your ma¬ 
chine is present. If so, it sets perform¬ 
ance parameters accordingly. Otherwise, 
it conducts a series of low-level tests to 
calculate the required parameters. Once 
the system is tuned, the installation pro¬ 
cedure runs a setup program to set sys¬ 
tem configuration switches. These 
switches can be changed later by running 
the setup program again. 

You can test the success of the instal¬ 
lation procedure by executing the dem¬ 
onstration programs included on the dis¬ 
tribution disks. To actually run a pro- 
tected-mode program from DOS, you 
must first load the operating system ker¬ 
nel by typing OS/x86 at the DOS prompt 
and then executing the program with the 
loader, UP. 

The main components of the OS/x86 
developer’s kit are the operating system 
kernel (OS/x86), a loader (UP), a pro- 
tected-mode debugger and command-line 
interpreter (CP), and a postprocessor 
(Express) for converting existing real¬ 
mode programs to protected mode. OS/ 
386 includes a separate 32-bit linker. The 
system disk also includes a set of library 
patches for a number of 16-bit compilers, 
such as Lattice C 4.2, Microsoft C Ver¬ 
sion 4.0, and Microsoft C Versions 5.0 
and 5.1. The libraries for your specific 


compiler must be patched before you can 
use them in protected-mode programs. 

During the development process, the 
OS/x86 operating system kernel is nor¬ 
mally loaded as a TSR, but you can also 
bind it to the executable program for dis¬ 
tribution as a single application file. The 
kernel controls program operation in pro¬ 
tected mode, providing the vehicle for 
communication with the real-mode DOS 
and system BIOS. 

The loader requires that the OS/x86 
kernel be resident before it can be exe¬ 
cuted. It receives the name of the pro- 
tected-mode executable program, to¬ 
gether with any arguments required. It 
then invokes the kernel to manage pro¬ 
gram execution. 

The protected-mode command-line in¬ 
terpreter and debugger (CP) also requires 
the operating system kernel to be resi¬ 
dent for its execution. It can be used as a 
loader in place of the standard UP 
loader. CP is a powerful command proc¬ 
essor, allowing you to execute any DOS 
command and any program you could 
execute under the normal DOS command 
interpreter. Normal DOS variables, such 
as Path, are also accessible from CP. In 
addition, CP offers a number of useful 
extensions to DOS, such as extended 
batch file processing, multiple com¬ 
mands on a single line, an Emacs-style 
command-line editor, and command ali¬ 
ases or synonyms. Since CP can execute 
commands from a batch file, it can be 
viewed as a programmable debugger. In 
fact, it depends heavily on this feature, 
since the basic set of debugging com¬ 
mands is rather limited. 

Eclipse supplies a number of com¬ 
mand files, which extend the debugger, 
and provides examples for incorporating 
your own command set. CP supports 
symbolic debugging, but not source-level 
debugging, and does not incorporate any 
windowing features. If you are accus¬ 
tomed to an interactive source level like 
those supplied with Turbo C or Micro¬ 
soft C, then the lack of these features 
will prove disappointing. In every other 
respect, however, I found CP to be more 
than adequate, with the added command¬ 
line features a definite benefit. 

The Express utility converts an exist¬ 
ing, well-behaved, real-mode executable 
program, together with the companion 
Map file created from your linker, into 
an equivalent protected-mode program 
that can execute in 286 protected mode. 
Express produces an Xmap map file and 
an Exp executable file, which can then 
be loaded and run using the UP loader. 
Programs created with either MS-Link or 
Plink86 must use Express to create a 286 
protected-mode program. However, pro¬ 
grams created with the Lahey Computer 
Systems Link-EM or the Phar Lap 386/ 
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procedures. 


Link linker do not need to be processed 
with Express. 

Eclipse Computer Solutions provides a 
Bind utility for combining your pro- 
tected-mode program, the loader, and the 
operating system kernel into a single ex¬ 
ecutable program that you can run from 
the DOS command line. The utility is not 
supplied with the developer’s kit; you 
must request it separately from Eclipse 
(at no additional charge). 

The Eclipse Computer Solutions sys¬ 
tem supports virtual 8086 (V86) mode 
for the 386 processor. Any sufficiently 
well-behaved real-mode program will 
run in V86 mode and exist in a “virtual 
machine” in extended memory with ac¬ 
cess to a full 1 Mbyte of linear address 
space. The program does not compete 
with any other programs that would nor¬ 
mally run in conventional memory, such 
as DOS/BIOS, TSRs, network code, and 
system device drivers. The OS/x86 oper¬ 
ating system kernel, which runs in con¬ 
ventional memory, manages your pro¬ 
gram so that it behaves exactly as it 
would in real mode, but with much more 
memory available. Even processes 
spawned from your program do not com¬ 
pete for your memory space, since they 
also get their own virtual machine with a 
full 1-Mbyte address space. 

The Eclipse system provides an exten¬ 
sive set of facilities for communicating 
between real-mode and protected-mode 
procedures. Portions of your program 
can run in real mode, while the remain¬ 
der runs in protected mode. This feature 
is especially useful when you are using 
vendor libraries and do not have access 
to the source code for conversion to pro¬ 
tected mode. 

Real- and protected-mode portions of 
your program communicate through real 
procedure calls (RPCs) and real proce¬ 
dure signals (RPSs). An RPC is equiva¬ 
lent to a Far call from protected mode to 
a procedure running in real address 
space. Up to 4 Kbytes of data can be 
transferred to the real procedure using a 
system transaction buffer. A block trans¬ 
fer call can also be used to transfer data 
to the real procedure. An RPS allows ei¬ 
ther a real-mode or protected-mode pro¬ 
cedure to send information to a pro¬ 


tected-mode process while maintaining 
program control. Any real-mode proce¬ 
dure can issue an RPS through the sys¬ 
tem kernel, as can any protected-mode 
task. Real procedure signals are proc¬ 
essed by signal handlers set by the pro¬ 
tected-mode process. Access to these 
handlers is provided by handles supplied 
to the issuing process by the protected- 
mode task. 

OS/x86 provides a number of addi¬ 
tional services that extend DOS’ capa¬ 
bilities. These include 

• automatic enabling of paging for the 
386 version of the kernel, 

• access to low memory (below 1 
Mbyte) for heap management, 

• use of a global name table permitting 
the passing of data values assigned to 
an 8-character name, 

• designation of up to eight 64-Kbyte 
segments that can be shared between 
parent and child processes, 

• the ability to write to a code seg¬ 
ment, and , 

• the ability to write beyond the end of 
a data segment. 


The Phar Lap extender 
requires a 32-bit compiler 
for you to program in a 
high-level language, plus 
recompilation of your 
source code. 


All of these features make the Eclipse 
system easily the most flexible of the 
DOS extenders available today. 

The documentation package for the 
Eclipse DOS extender system consists of 
a single spiral-bound manual (the same 
manual for both OS/286 and OS/386) 
and an extensive set of programming ex¬ 
amples. The documentation is easily the 
best I have encountered for a product of 
this type. It not only includes an excellent 
set of reference material, but also a thor¬ 
ough description of protected-mode fa¬ 
cilities and the theoretical approach used 
by Eclipse in developing the product. 

OS/286 and OS/386 Developer’s Kits, 
Version 2.0.10, are available from 
Eclipse Computer Solutions, One Inter¬ 
national Way, Peabody, MA 01960, 
phone (508) 535-7510. 

OS/286: Reader Service 22 
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Phar Lap 386/DOS- 
Extender 

The Phar Lap 386/DOS-Extender is in¬ 
cluded as part of the 386/ASM/Link 386 
MS-DOS Development Package. It in¬ 
cludes the 386/ASM assembler, the 
386/Link linker, the 386/Lib librarian, 
the development version of the 386/ 
DOS-Extender protected-mode runtime 
environment, and the Minibug debugger 
for both real-mode and 386/DOS- 
Extender programs. The package sells 
for $495 and can be used to build devel¬ 
opment versions of your protected-mode 
programs. 

The 386/DOS-Extender Redistribution 
Kit, priced at $1,495, includes a redistri¬ 
bution version of the 386/DOS-Extender 
environment along with a binder utility 
to combine the 386/DOS-Extender and 
your program into a single executable 
file run directly from the DOS command 
line. There is no per-copy fee for distrib¬ 
uting the end-user application. 

The 386/ASM/Link Development 
Package comes on five 5.25-inch low- 
density (360-Kbyte) diskettes. These 
disks include all of the executable pro¬ 
grams you will require for development, 
a set of test programs for verifying cor¬ 
rect installation of the assembler and 
linker, and an extensive set of example 
programs for demonstrating the different 
forms of 386-specific programming. 
Batch files for assembling and linking 
the test programs also come on the distri¬ 
bution disks. There is no extensive in¬ 
stallation procedure — you need only 
copy the required files to the directory of 
your choice. 

The 386/DOS-Extender is intended 
only for the 386 processor, so you will 
need a 32-bit compiler to program in a 
high-level language, and you will need to 
recompile all of your source code. As¬ 
sembly language source code must be as¬ 
sembled with the Phar Lap 386/ASM as¬ 
sembler. You can use the Phar Lap 386/ 
Link linker to link the object files for the 
386 protected mode. The protected-mode 
program produced by the linker can be 
used with the development version of 
the 386/DOS-Extender without further 
processing. 

The development version comes as a 
single .exe file. You can use it to load 
your program by typing run386 followed 
by any command-line switches and the 
name of your protected-mode program. 

The runtime version of 386/DOS-Ex¬ 
tender also comes as a single executable 
file, but it must be bound to your appli¬ 
cation using the Bind386 utility program 
supplied by Phar Lap when you purchase 
the runtime license with the redistribu¬ 
tion kit mentioned above. Any com- 
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mand-line switches required for the run¬ 
time program must be configured in the 
task image with the Cfig386 utility pro¬ 
gram. This is the only way to include 
switches into the task image, since 386/ 
DOS-Extender does not process the com¬ 
mand line. You can also use the Cfig386 
utility to configure command-line 
switches in the development version of 
your program. 

386/DOS-Extender provides an exten¬ 
sive set of command-line switches to 
control the way the system uses conven¬ 
tional memory and extended memory, 
the loading of mixed-mode (real and pro¬ 
tected) programs into portions of conven¬ 
tional memory and extended memory, 
the remapping of interrupt vectors, the 
size of the data buffers used for DOS and 
BIOS function calls, and the way the sys¬ 
tem interacts with the Vdisk standard for 
allocating extended memory. With the 
Cfig386 utility you can include the speci¬ 
fication of each of these parameters in 
the final task image. 

386/DOS-Extender builds and main¬ 
tains a GDT to map its own segments 
and an LDT to map segments belonging 
to the application program. The applica¬ 
tion program has access to a number of 
important program segments through a 
set of predetermined segment selectors 
established by 386/DOS-Extender in the 
LDT when the protected-mode program 
is first loaded into memory. These in¬ 
clude the MS-DOS program segment 
prefix (PSP), which contains the com¬ 
mand line passed to the program when 
execution begins; the physical memory 
for the display screen for programs wish¬ 
ing to update the display memory di¬ 
rectly for the sake of speed; and the MS- 
DOS environment block for programs 
geared to use environment variables to 
control program behavior. Your program 
can access any of the data in these seg¬ 
ments from protected mode. Additional 
segment descriptors are established in 
the LDT whenever your program per¬ 
forms a memory allocation system call. 

386/DOS-Extender allows your pro¬ 
gram to spawn a secondary process with 
the Exec system call to either a real¬ 
mode program or a protected-mode pro¬ 
gram. If the child program is a real-mode 
program, there must be enough conven¬ 
tional memory available to load the pro¬ 
gram. If the child program is a protected- 
mode program, there must be enough 
free conventional memory to load a sec¬ 
ond copy of 386/DOS-Extender and 
enough additional conventional or ex¬ 
tended memory available to support your 
program. This uses approximately 200 
Kbytes of conventional memory for cop¬ 
ies of the extender itself, 100 Kbytes for 
the initial copy, and another 100 Kbytes 
for the secondary copy to support the 
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child process. 

MS-DOS system calls, as well as 
BIOS system calls, are made with soft¬ 
ware interrupts when in protected mode, 
the same as in real mode. 386/DOS-Ex- 
tender traps the interrupt, switches the 
processor to real mode, modifies any 
function parameters if necessary, and re¬ 
issues the interrupt to MS-DOS. You 
don’t need to master two separate calling 
protocols. 

Interrupts occurring in protected 
mode, whether a hardware interrupt, a 
software interrupt, or a processor excep¬ 
tion, are always handled by 386/DOS- 
Extender unless your program has modi¬ 
fied the interrupt vector table entry for 
the interrupt. When the extender gains 
control, it switches the processor to real 
mode, reissues the interrupt as a software 
interrupt, and switches back to protected 
mode when the interrupt handler has fin¬ 
ished. Since the ability to switch from 
real mode to protected mode or from pro¬ 
tected mode to real mode is huilt into the 
386, the overhead is considerably less 
than for a similar scenario on the 286. 
Estimates for a single mode switch range 
from 90 microseconds for a 16-MHz 386 
to 58 microseconds for a 25-Mhz system. 

386/DOS-Extender provides three 
separate methods for mixing real- and 
protected-mode code within a single pro¬ 
gram. The first method requires you to 
link the real- and protected-mode code 
into a single executable program and bet¬ 
ter suits assembly language programs 
than high-level language programs. The 
second method requires you to build two 
separate executable programs, one for 
protected mode and one for real mode. 
The protected-mode program then per¬ 
forms an Exec system call to the real¬ 
mode program. This method is particu¬ 
larly easy to implement, but communi¬ 
cating between the two programs pres¬ 
ents a number of difficulties. The third 
option resembles the second, except that 


the real-mode program performs the 
Exec system call to the protected-mode 
program. 

386/DOS-Extender allows you to allo¬ 
cate a buffer in conventional memory at 
system initialization time. The buffer can 
be as large as 64 Kbytes. Since both the 
real-mode and protected-mode addresses 
of the buffer are available at runtime, 
your application can define any protocol 
it chooses for passing data back and forth 
between your real- and protected-mode 
programs. The product distribution disks 
provide a number of examples of pro¬ 
gramming in mixed mode. 

The 386/ASM/Link package includes a 
protected-mode debugger called Minibug 
with a command structure similar to the 
Debug utility furnished with MS-DOS. A 
more advanced debugger called 386/De¬ 
bug can be purchased separately from 
Phar Lap for $195, but unfortunately nei¬ 
ther Minibug nor 386/Debug is a source- 
level debugger. 

Contact Phar Lap Software at 60 Aber¬ 
deen Ave., Cambridge, MA 02138, 
phone (617) 661-1510. 
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Summing up 

Each of the DOS Extenders examined 
in this review is an excellent product, 
with unique features that make a choice 
of one package difficult. 

The Rational Systems kernel is much 
smaller than the others, making it ideal 
for use with TSRs. Although compatible 
with both 286 and 386 protected mode, it 
does not take advantage of the 386 linear 
32-bit addressing capabilities or paging 
mechanism. 

The Eclipse Computer Solutions prod¬ 
uct is available for either the 286 or 386 
and offers the most flexible set of fea¬ 
tures, especially in the area of communi¬ 
cation between real and protected mode. 
It is also the most adept at separating 
portions of code running in real mode 
from code running in protected mode. 
This lets you use existing real-mode 
commercial libraries with your pro¬ 
tected-mode programs. 

The Phar Lap package directly targets 
the 386 processor and takes advantage 
of its full capabilities, including virtual 
memory. The package also includes an 
excellent assembler and linker, a set 
not included with either of the other 
products. 

If you face the memory limitations 
imposed by DOS and want to extend the 
life of your applications, the tools are 
available now in the form of DOS ex¬ 
tenders. The packages I looked at are all 
excellent. 
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A C language compiler for the 386 


Daniel McAuliffe 


If you plan to take advantage of the 
additional capabilities of the 386 proces¬ 
sor by adopting one of the DOS exten¬ 
ders reviewed in this column, you will 
need an assembler or compiler, possibly 
both, for generating 32-bit code and data. 
If you choose the Phar Lap 386/ASM/ 
Link package, the 386 assembler is in¬ 
cluded. For any other DOS extender, you 
will have to purchase a separate assem¬ 
bler. 

No matter which DOS extender you 
select, you must purchase a compiler if 
you plan to program in a high-level lan¬ 
guage. Most Fortran and C compilers for 
the 386 processor carry a retail price in 
the neighborhood of $800 to $900, a 
rather substantial investment, so you 
would be wise to spend some time inves¬ 
tigating the different products available. 

To test the different DOS extenders 
for this review, I used the MetaWare 
High C-386 compiler. 


Installation 

The basic MetaWare High C-386, Ver¬ 
sion 1.6, system is furnished on two 
5.25-inch 1.2-Mbyte high-density disk¬ 
ettes containing the compiler, the support 
libraries, various demonstration pro¬ 
grams, and miscellaneous utilities. Most 
of the files on the diskettes are com¬ 
pressed, so you must use the MetaWare 
installation procedure to decompress and 
load them onto your hard disk. The in¬ 
stallation process requires approximately 
5 Mbytes of disk space if you choose to 
install all of the material provided. How¬ 
ever, you can elect to exclude any num¬ 
ber of the subsystems, such as the DOS 
helper, the Make utility, the example 
programs, and the demonstration pro¬ 
grams. The installation procedure is 
painless and much improved over the 
procedures supplied with previous ver¬ 
sions of this compiler. 

Two separate versions of the compiler 
come with the system, both of which you 
can install on your hard disk at the same 
time. The first version runs in the nor¬ 
mal DOS real-mode environment, while 
the second version, which is functionally 
equivalent to the first but runs in pro¬ 
tected mode, was built with the Phar Lap 
DOS/Extender and requires a 386 proc¬ 
essor. The protected-mode version will 
compile your programs faster than the 
real-mode version and can also compile 
much larger programs, since it resides in 


extended memory during the compilation 
process. 

To use the real-mode version of the 
compiler, you will need at least 384 
Kbytes of RAM. The protected-mode 
version will require a minimum of 1.5 
Mbytes of available RAM. Each execut¬ 
able program requires approximately 1 
Mbyte of disk space. MetaWare does not 
supply a linker or a protected-mode de¬ 
bugger — you must furnish your own. 
Moreover, the linker must be either the 
Phar Lap 386/Link or the Lahey L32 
linker. All demonstration programs sup¬ 
plied with the product are set up to be 
linked and run with the Phar Lap linker 
and loader. 

MetaWare provides a number of dif¬ 
ferent methods for configuring the com¬ 
piler once it is successfully installed. A 
special stand-alone Config program is 
provided for compatibility with older 
versions of the system, although Meta¬ 
Ware specifically warns against relying 
on the program, since it will not be sup¬ 
ported in future releases. Config prompts 
you for the appropriate options, then in¬ 
cludes their values directly in the com¬ 
piler executable image. 

The recommended method of config¬ 
uring the compiler is to include the de¬ 
fault values of your variables and options 
in a configuration file. Two such files are 
provided: hc386.cnf, the long form of the 
configuration file, includes many more 
options than you will want to modify; 
hc386set.cnf, a short form of the con¬ 
figuration file, includes the variables you 
are likelier to change. The short form is 
included within the long form. The vari¬ 
ables and options you can modify in the 
configuration file are quite extensive and 
include such items as the location of the 
linker you will be using, the location of 
any supplementary libraries, and any de¬ 
fault command-line arguments. 

Profiles provide a third method for 
configuring compiler options. A profile 
is a file the compiler reads just before it 
loads your source file. You can use it to 
initialize the values of program pragmas, 
which are commands to the compiler. 
Pragmas can also be set from within the 
source module to control such features as 
program listing, the path for the inclu¬ 
sion of header files, and listing titles. 

The newest release of the MetaWare 
High C-386 product is distributed with a 
“driver” program that allows you to com¬ 
pile and link with a single command. 
Normally, you would invoke the driver 


from the command line, which in turn 
would invoke the compiler and then the 
linker to produce the executable file. 
Here, you can instead invoke the com¬ 
piler and linker separately from the 
command line or a batch file. The con¬ 
figuration files mentioned above are read 
by the driver program and, in fact, are 
written in a unique MetaWare driver 
language. 

Testing 

The first version of the High C-386 
distribution kit I received (Version 1.5) 
contained a defective disk, but the com¬ 
pany responded quickly when asked for a 
replacement. I installed the system and 
first used the compiler with the Phar Lap 
386/DOS-Extender to compile and exe¬ 
cute the sample programs supplied by 
MetaWare. On a 386 machine with 2 
Mbytes of memory, all programs ran 
properly using both the real- and pro¬ 
tected-mode versions of the compiler. 

I then tried the compiler with a set of 
demonstration programs supplied with 
the 386-compatible version of a popular 
commercially available interface-man¬ 
agement system. With the real-mode ver¬ 
sion of the program I got “dynamic array 
allocation” errors, apparently because of 
the size of the Include files required by 
the commercial libraries. The protected- 
mode version of the compiler gave “out 
of memory” errors with the same pro¬ 
grams. On a 386 machine with 8 Mbytes 
of memory, only the protected-mode ver¬ 
sion of the compiler was able to compile 
the programs. 

Although eventually I got all of my 
test programs to run, it was obvious that 
the compiler needed lots of memory to 
compile even modestly sized programs. 

A glance at some of the error messages 
generated hy the compiler may indicate 
why the program demands so much 
memory. It must be the most verbose 
system on the market. Some error mes¬ 
sages ran many lines, yet because of 
their cryptic nature, I had to refer to the 
manual for an explanation of their 
meanings. 

I must admit, however, that the com¬ 
piler was very adept at spotting potential 
sources of error in the code I used for 
testing. For example, the test for the 
value of X in the phrase “if (x = y)” 
caused a warning message concerning 
the use of “=” in place of “==.” Using 
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the more appropriate code fragment “if 
((^ = y) != 0)” eliminated the warning. 
Most other compilers would have passed 
over the original phrase without com- 

Subsequent to this testing, I received a 
copy of Version 1.6 of the High C-386 
system. I installed it and attempted to run 
the demonstration programs, only to find 
that the protected-mode version of the 
compiler consistently reported problems 
with the heap. I then abandoned the 
driver program and attempted to compile 
the programs with the protected-mode 
compiler directly from the command 
line. At that point the compiler reported 
dynamic memory allocation problems, so 
I removed all the TSRs in the system and 
tried again. I again received reports com¬ 
plaining about the heap. I then tried run¬ 
ning the demonstration programs using 
the real-mode version of the compiler, 
and all the programs ran properly. 

While conducting these tests, I re¬ 
ceived word that MetaWare was sending 
along an update disk to correct a problem 
with a header file. Thinking that the up¬ 
date would alleviate my rising frustra¬ 
tion, I abandoned any further testing of 
the protected-mode compiler until the 
disk arrived. When I received the disk, 
the accompanying instructions told me to 
simply copy a “limits.h” file from the 
distribution disk to the hard disk. Unfor¬ 
tunately, the distribution disk contained 
only compressed files, with no uncom¬ 
press utility, so I was forced to reinstall 
the entire system. I then retested the pro¬ 
tected-mode version of the compiler and 
found all of the same problems men¬ 
tioned above. At this point I gave up on 
the protected-mode compiler and concen¬ 
trated on testing the real-mode version. 
Obviously, MetaWare has some serious 
quality-control problems. 


Review notes 

Cellular automata. If you want to 
learn about or get hands-on experience 
with cellular automata, try CA Lab 
($59.95), one of the better offerings in 
this area. It lets you conduct such ex¬ 
periments without special hardware. 

A cellular automaton is a collection 
of identical automata organized in a re¬ 
petitive, spatial pattern. CA Lab pro¬ 
vides both one- and two-dimensional 
lattices, with and without edge wrap¬ 
ping (a line becomes a ring and a rec¬ 
tangle becomes a torus). Each automa¬ 
ton communicates with a subset of its 
neighbors within a distance that is 


Utilities 


The standard library provided with 
MetaWare High C-386, Version 1.6, is 
much improved over previous versions. 

It provides all of the ANSI standard 
functions, as well as a number of exten¬ 
sions to the standard and many non- 
ANSI functions. It includes a complete 
set of functions for interfacing with the 
ROM BIOS and DOS services, constants, 
and structures. If you have a number of 
real-mode programs written with the 
Microsoft compiler that make extensive 
use of DOS interface functions provided 
by Microsoft, these new library additions 
will make their conversion to the pro¬ 
tected mode provided by MetaWare a 
much smoother process. 

The newest release of High C-386 is 
bundled with three new and significant 
products for the 386 environment. Two 
are supplied by Sterling Castle Software. 
One, the Blackstar C Function Library, 
consists of a set of more than 300 func¬ 
tions covering everything from ANSI 
console services to system functions to 
serial port control functions. The second 
is a B+ tree data management system. 
Both of these products come with full 
source code. The third item in the 
bundled set is the GFX Graphics and 
Font Library from C Source. It includes a 
full set of graphics primitives and higher 
level functions that operate in protected 
mode. The source code is not provided 
for this item but is available separately. 

High C-386 includes a number of 
other useful and interesting utilities 
along with the compiler. HyperDisk is a 
disk-caching program that can substan¬ 
tially increase disk throughput, espe¬ 
cially when compiling very large pro¬ 
grams. HyperKey is another of the popu¬ 


small relative to the number of auto¬ 
mata in a single dimension. CA Lab 
supports a predefined distance of one 
(like nearest neighbors). 

The action of a cellular automaton is 
to fire (invoke the execution of) each 
automaton in the array once at each in¬ 
stant of (simulated) time. The inputs 
are the states of the neighboring auto¬ 
mata. The speed with which all of 
these automata can be fired determines 
the smoothness of the visual effect 
seen on the display. 

CA Lab consists of RC and CA, 
both of which run on an IBM PC or 
compatible under DOS. You need a 
color display to get the full impact. 


lar keyboard-enhancement-style prod¬ 
ucts. Also included is a copy of DOS 
Helper and a set of Unix-style utility pro¬ 
grams such as Cat, Fgrep, Find, LS, MV, 
and WC. It was a pleasant surprise to see 
such a useful set of programs included 
with the package, since they are indis¬ 
pensable tools for every professional 
programmer. The High C-386 system 
also includes a copy of the programmer’s 
editor, EC, a product published by C 
Source. 


Summing up 

Although the MetaWare High C-386 
package contains a useful set of software 
development tools, it is by no means 
complete. As mentioned previously, the 
lack of a linker requires you to purchase 
either the Phar Lap 386/Link or Lahey 
L32 linker. For any serious protected- 
mode development, you will also need to 
purchase a debugger. Both of these prod¬ 
ucts are generally included along with 
the DOS extender you will also need to 
run your programs. 

The MetaWare High C-386 compiler 
is a powerful tool for building programs 
targeted specifically at the 386 or 486 
processor, but it is large and verbose, and 
navigating your way through its many 
temperamental features requires a great 
deal of effort. Before investing in this 
product, you would be well advised to 
consider other vendors of 386 C lan¬ 
guage compilers. 

High C-386, Version 1.6, is available 
from MetaWare, 2161 Delaware Ave., 
Santa Cruz, CA 95060-5706, phone 
(408) 429-6382. The retail price is $895. 
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RC is preprogrammed with many 
patterns. It uses character mode. A 
double mode doubles the number of 
lines. One of its advantages is its 
speed. It requires 256 Kbytes of RAM. 

CA provides a more refined grid, but 
requires 512 Kbytes of RAM. CA is 
more flexible than other such pro¬ 
grams, since you can program it. 

I found CA Lab well implemented, 
easy to use, and very well documented. 
In fact, the documentation is among 
the best I've read. Rudy Rucker, an 
award-winning author, wrote it. 

Autodesk, 2320 Marinship Way, 
Sausalito, CA 94965, phone (415) 331- 
0356 or (800) 525-2763. — C. Kaman 
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NEW PRODUCTS 


Contact or send releases to Nancy Hays, Computer, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720; Compmail +, n.hays 


IBM powers up new RISC workstations and servers 


IBM has based the RISC System/6000 
family of workstations and servers on its 
Power (Performance Optimization with 
Enhanced Reduced Instruction Set Com¬ 
puting) architecture. According to the 
company, the new systems incorporate 
an implementation of the Micro Channel 
bus architecture, a superscalar processor 
capable of executing multiple instruc¬ 
tions in a single cycle, a RISC floating¬ 
point processor, and optimized 3D 
graphics capabilities. They run AIX, 
IBM’s implementation of the Unix oper¬ 
ating system. 

The 20-MHz Powerstation 320 desk¬ 
top workstation reputedly achieves a per¬ 
formance of 27.5 MIPS and 7.4 Mflops. 

It features two memory slots and four 
32-bit MCA slots. Scheduled for availa¬ 
bility in the second quarter, it will cost 
$12,995 and up for a fully configured 
client system and $14,945 and up for a 
stand-alone workstation configuration. 
This includes a 19-inch 1,280x1,024 
monochrome display, graphics adapter, 
Ethernet, keyboard, mouse, AIX operat¬ 
ing system, graphical user interface, soft¬ 
ware service, and warranty. 

The Powerstation 520 deskside unit 
runs at 20 MHz. A base configuration 
comes with 8 Mbytes of memory, a 3.5- 
inch 1.4-Mbyte floppy disk drive, and a 

5.25-inch 355-Mbyte hard disk drive. It 
features eight memory slots and eight 
MCA slots. It reputedly achieves a per¬ 
formance of 27.5 MIPS and 7.4 Mflops. 
Available in the second quarter, it will 
cost $27,245 and up. 

The 25-MHz Powerstation 530 
deskside unit comes standard with 16 
Mbytes of memory, a 3.5-inch 1.4-Mbyte 
floppy disk drive, a 5.25-inch 355-Mbyte 
hard disk drive, eight memory slots, and 
eight MCA slots. Performance is rated at 
34.5 MIPS and 10.9 Mflops. Available in 
the second quarter, it will cost $42,705 
and up. 

The 25-MHz Powerstation 730 
deskside system is a 3D graphics work¬ 
station with a 1,280x1,024-pixel resolu¬ 
tion monitor and support for 16.7 million 
colors. It features IBM’s Supergraphics 


Processor Subsystem. A base configura¬ 
tion comes with 16 Mbytes of memory, a 
3.5-inch 1.4-Mbyte floppy disk drive, a 

5.25-inch hard disk drive, eight memory 
slots, and eight MCA slots for $73,815. 

It is scheduled for the fourth quarter. It 
reputedly achieves performance of 34.5 
MIPS and 10.9 Mflops. 

The Powerservers include the deskside 
model 320 starting at $20,375, the model 
520 starting at $30,425, the model 530 
starting at $41,125, and the 30-MHz 
rack-mounted model 930 starting at 
$62,230 (in the third quarter). The Pow- 
erserver 930 in a base configuration fea¬ 
tures 16 Mbytes of memory, a 3.5-inch 
1.4-Mbyte disk drive, a 2.3-Gbyte tape 
drive, a 600-Mbyte CD-ROM drive, a 

5.25-inch 670-Mbyte hard disk drive, 
eight memory slots, and eight MCA 
slots. 

The Powerserver base configuration 
models include Ethernet, AIX, and a 
150-Mbyte 0.25-inch tape drive. 

IBM also plans to offer a complemen¬ 
tary LAN-attached X server terminal 
called the Xstation 120. According to the 



IBM’s RISC System/6000 Powerstation 
320 reputedly hits 27.5 MIPS. 


company, an Xstation 120 can run simul¬ 
taneously in a Token-Ring and an Eth¬ 
ernet network. 

A base configuration Xstation 120 in¬ 
cludes an I/O processor, a graphics pro¬ 
cessor, 512 Kbytes of system memory 
(expandable to 8.5 Mbytes) and 512 
Kbytes of video memory (expandable to 
2 Mbytes). It also comes with serial and 
parallel ports. 

The Xstation 120 works with a wide 
variety of displays. Available in the sec¬ 
ond quarter, it will cost $2,525 and up. 
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Motorola Multipersonal Computer combines ALR supports EISA with 

networking, graphics, and RISC new systems 




Motorola’s Computer 
Group has based the Multi¬ 
personal Computer on its 
M88000 reduced instruction 
set computing microproces¬ 
sor and the VMEbus architec¬ 
ture. The Unix-based com¬ 
puters come standard with 
local area network support. 

Each system comes with 
one license and copy of Uni- 
plex II Plus, an office auto¬ 
mation software package 
from Uniplex. Also included 
is SoftPC, a software emula¬ 
tor for MS-DOS programs; a 
trial copy of FrameMaker corporate pub¬ 
lishing software for Unix systems, from 
Frame Technology; System V/88, 
Motorola’s Unix System V Release 3 op¬ 
erating system; X Window System gra¬ 
phical environment; OSF/Motif window 
manager; Looking Glass desktop man¬ 
ager; and Ethernet. 

The Multipersonal Computer comes in 
three models. Each comes standard with 
the company’s Network Display Station, 
available in 16- and 19-inch mono¬ 
chrome or 17-inch color models. The 
high-resolution, X-compliant display sta¬ 
tions feature built-in networking and 
processing capabilities, according to the 
company. 

Model 100 includes a 20-MHz 
MC88100 CPU. It features 300-600 
Mbytes of SCSI Winchester disk storage, 
16-32 Mbytes of RAM, a 150-Mbyte 


streaming tape backup subsystem, a re¬ 
mote-diagnostics modem, two RS-232-C 
asynchronous ports, Ethernet and TCP/IP 
network software, and three 16-inch Net¬ 
work Display Stations. It costs $7,995 
per seat, or $23,985. Model 100 supports 
from three to six active X Stations. 

Model 200 includes a 25-MHz 
MC88100 CPU, 16-48 Mbytes of RAM, 
two RS-232-C asynchronous ports, 600- 
1,200 Mbytes of SCSI Winchester disk 
storage, a 150-Mbyte streaming tape 
drive, and three 16-inch Network Dis¬ 
play Stations. It costs $35,985, or $7,304 
per seat. Model 200 supports from three 
to 16 active X Stations. 

Model 300 features a 25-MHz 
MC88100 CPU, 32-64 Mbytes of RAM, 
two RS-232-C asynchronous port, 1,200- 
2,400 Mbytes of SCSI Winchester disk 
storage, a 150-Mbyte streaming tape 
drive, and three 19-inch Network Dis¬ 
play Stations. It costs $59,985, or $6,597 
per seat. Model 300 supports from three 
to 32 active X Stations. 
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Motorola’s Multipersonal Computer family includes three models built around 
its 88100 RISC CPU and Unix: 100 (top), 200 (middle), and 300 (bottom). 


Advanced Logic Research has built 
three new systems around its Power- 
VEISA architecture; PowerVEISA 386/ 
33, PowerVEISA 486/25, and Power¬ 
VEISA 486/33. They are scheduled for 
shipment in the second quarter. 

The systems incorporate a 32-bit EISA 
I/O bus with 8- and 16-bit compatibility, 
the company’s Flexcache design, and 
scalable CPUs. The PowerVEISA 386/33 
will allow upgrading to 25- and 33-MHz 
i486 technology, according to ALR. 

The PowerVEISA systems come with 
5 Mbytes of RAM standard, a 64-Kbyte 
cache, a 5.25-inch 1.2-Mbyte floppy disk 
drive, nine slots total, one serial port, 
one parallel port, one mouse port, Phoe¬ 
nix BIOS, and an MCS EISA utility. The 
150- and 33-Mbyte systems use a 20- 
MHz EISA-based ESDI controller with a 
64-Kbyte look-ahead cache. 

The new systems will be available in 
three models with 80-, 150-, and 330- 
Mbyte storage. Prices for the Power¬ 
VEISA 386/33 range between $5,795 
and $9,795. The PowerVEISA 486/25 
costs from $7,495 to $11,495. The Pow¬ 
erVEISA 486/25 ranges in price from 
$8,495 to $12,495. 

Upgrade modules are the Power¬ 
VEISA 486/25 Module for $1,995 and 
the PowerVEISA 486/33 Module for 
$3,195. 
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RDBMS provides SQL 

Coromandel’s Integra Relational Data¬ 
base Management System is based on 
Structured Query Language. According 
to the company, Integra RDBMS inte¬ 
grates data from other databases and file 
formats without conversions or import¬ 
ing of data, provides ANSI-level SQL 
facilities compatible in the Windows and 
Unix environments, allows developers to 
develop ISAM-based applications and 
move them to SQL, uses about half of 
the 640-Kbyte environment, and is avail¬ 
able unbundled, as separate products. 

Integra RDBMS consists of an SQL 
Engine, a front end, a report writer, and 
an applications development toolkit. It is 
available under DOS, Xenix, and Unix. 
The company plans to offer future ver¬ 
sions under Sun OS, Windows, OS/2, 
and VAX VMS. 

Integra RDBMS costs $695 for DOS 
and $995 for Xenix or Unix versions. 
Source code is available. 
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Toshiba notebook line gains power, storage with new models 


Toshiba offers two new models in its 
family of notebook-sized PCs. 

The T1200XE incorporates a 12-MHz 
80C286 microprocessor, a 25-ms 20- 
Mbyte hard disk drive, a 3.5-inch 1.44- 
Mbyte floppy disk drive, and 1 Mbyte of 
RAM expandable to 5 Mbytes. The PC 
weighs 7.9 pounds and measures 
12.2x2x11 inches. It comes with a re¬ 
movable NiCad battery, plus a nonre¬ 
movable NiCad battery to back up sys¬ 
tem memory. 

The T1200XE features a side-lit super¬ 
twist LCD with 640x400 double-scan 
CGA compatibility, an 82-key keyboard 
with 12 function keys and eight dedi¬ 
cated cursor control keys, HardRAM, 
and Autoresume. HardRAM acts like a 
nonvolatile virtual disk, according to the 
company, while Autoresume permits 
users to turn off the power and turn it 
on again without losing position in an 
application. 

The T1200XE costs $3,999. 

Standard software includes MS-DOS 
4.01, PC Kwik Power Pak, and Hyper¬ 
text including a T1200XE reference and 
DOS manuals. 

Options include 2-Mbyte memory 
cards for $1,099 each, a 2,400-baud 
modem for $349, a 17-key numeric 
keypad for $99, a battery pack for $79, 


a three-pack battery recharger for $349, 
an auto adapter for $129, and a carrying 
case for $99. 

The TIOOOXE is a hard disk version of 
the TIOOOSE. It weighs 6.2 pounds and 
measures 12.2x10x1.8 inches. It includes 
an 82-key keyboard with 12 function 
keys, a 9.54-MHz 80C86 microproces¬ 
sor, a CGA-compatible back-lit super¬ 
twist LCD with 640x400-pixel resolu¬ 
tion, 1 Mbyte of RAM, a rechargeable 
battery pack, and a 20-Mbyte hard disk 
drive with 25-ms average access time. 

MS-DOS 3.3 and Laplink come loaded 



New architecture powers 
graphics supercomputers 

Silicon Graphics has announced the 
Iris Powervision family of graphics 
supercomputers, part of the Iris Power 
Series. According to the company, Pow¬ 
ervision combines interactive geometric 
processing and image processing based 
on a new graphics architecture. The new 
architecture reputedly provides perfor¬ 
mance of 1 million polygons per second, 

1 million anti-aliased vectors per second, 
and 1.5 million anti-aliased points per 
second. 

Features include real-time anti-aliasing 
of polygons, vectors, and points; real¬ 
time texture mapping; real-time special 
effects for fog, motion-blur, and full- 
scene progressive anti-aliasing; and a 
suite of imaging functions. 

Powervision comes as a new system or 
as a field-installable upgrade to the exist¬ 
ing Power Series line. System prices be¬ 
gin at $94,900. To upgrade from a GTX 
system costs $40,000. 

Powervision is scheduled for availabil¬ 
ity in June 1990. 
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Library links C and EMM 

Silverware’s C EMM Library pro¬ 
vides an interface between C programs 
and the Expanded Memory Manager de¬ 
vice driver. Using EMM allows program¬ 
mers to add up to 32 Mbytes of space for 
data storage. Because the C EMM Li- 


Cadysis has announced Autohybrid, a 
system for hybrid circuit design on per¬ 
sonal computers. Autohybrid reportedly 
allows a hybrid circuit designer working 
on a PC to begin a design from the 
system’s schematic capture facility. 
Printed thick film or thin film resistors 
called out in the schematics are automati¬ 
cally generated with geometries custom¬ 
ized to the designer’s specification. 

Given a list of resistive inks available 
to the design, the system can also auto¬ 
matically optimize the geometries to the 
best aspect ratio, taking into account the 
terminal endpoint effects. The company 
claims that the system can also accommo¬ 
date customized laser trimming factors. 


in ROM on the TIOOOXE. The PC also 
has Autoresume and a battery manage¬ 
ment system. 

The TIOOOXE costs $2,699. 
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Toshiba’s T1200XE notebook-sized PC 
features a 12-MHz 80C286 CPU and a 
20-Mbyte hard disk drive. 


Toshiba’s TIOOOXE is the company’s 
lightest PC with a hard disk drive. 


brary links C applications and EMM, us¬ 
ers will not need assembly code, accord¬ 
ing to the company. 

The library supports the Microsoft C, 
Microsoft Quick C, and Borland Turbo C 
compilers. 

The C EMM Library costs $199. 
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According to the company, once the 
die and wire bond pad locations are de¬ 
fined and placed on the substrate, the 
system automatically generates bond 
wires from the chip to pads on the sub¬ 
strate. Then the autorouter routes the 
traces according to the design rules 
specified by the designer. During auto¬ 
matic and manual routing, the on-line 
design rule checker checks the traces. 

Autohybrid is based on the AutoCAD 
graphic platform, and files generated are 
compatible with AutoCAD. It comes 
with a Gerber photo-plotter driver. 

Autohybrid costs $14,995. 
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Unix workstations turn into image processors 


Ramtek’s Millenium imaging system 
reportedly turns Unix workstations into 
image-processing computers. The 
Millenium subsystem connects to a Unix 
workstation through a VMEbus or SCSI 
link, offloading image processing and 
visualization from the workstation. 

Ramtek claims that Millenium per¬ 
forms floating-point calculations at the 
rate of 80 Mflops. It provides up to 16 
Mbytes of local memory and 30-Mbit/s 
local buses. This reportedly allows the 
system to perform fast Fourier trans¬ 
forms of images as large as 1,024x 1,024 
pixels and accelerate complex imaging 
operations. It also provides graphics dis¬ 
play capabilities through the X Window 
System, at performance levels acceler¬ 
ated by Texas Instruments’ TMS34020 
graphics processor. 

Millenium incorporates the Imaging 
Kernel System software developed by 
the University of Lowell in Massachu¬ 
setts. IKS complies with the proposed 
ANSI standard Programmer’s Imaging 
Kernel. 

Millenium is available as a three-board 
set for VMEbus backplanes or as a stand- 


Windows-compatible CASE 

Chicago Computer Works offers Per¬ 
sonal CASE 1.0, a graphics-based CASE 
program for systems designers using PCs 
compatible with Microsoft Windows. 

The software integrates dataflow dia¬ 
grams and data dictionaries in a Win¬ 
dows application. The data dictionary 
captures identification and descriptive 
information about each component of the 
design and stores the information in an 
ISAM file. 

According to the company, design dia¬ 
grams can consist of nearly unlimited 
pages, each with any number of diagram 
elements. The software supports an infi¬ 
nite hierarchy of design decomposition. 


alone seven-slot chassis with an SCSI 
interface. Shipments are scheduled for 
April. The stand-alone system costs 
$25,995 and the three-board set, 

$20,995. Both configurations include a 
TMS34020-based graphics board, a 
TMS34082/TMS34020-based imaging 
board, a 20-bit memory video board, and 
an IKS software license. 
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Ramtek’s Millenium imaging system 
comes as a three-board set or a stand¬ 
alone system, shown here. 


runs on PCs 

allowing users to break down any pro¬ 
cessing step to any number of levels of 
detail. The program includes the detail 
diagram pages in the hierarchy. 

Users can reportedly disable the dic¬ 
tionary. When enabled, the dictionary is 
integrated with the drawing operations. 
Dictionary information is automatically 
included in printed reports. 

Personal CASE supports multiuser 
LANs with MS-DOS file and record 
locking. It also supports top-down and 
bottom-up design. 

Personal CASE costs $199. 
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Multiuser entry-level systems target Pick market 


Alpha Microsystems has expanded its 
entry-level line with the 6- to 32-user 
AMS 1000 Series of business computers 
for markets served by the Pick operating 
system. The series relies upon Intel’s 
80386 CPU in its two desktop models, 
the AMS 1200 and AMS 1600. 

The AMS 1200 comes with a 16-MHz 
386SX-based processor, a 1.2-Mbyte 
floppy disk drive, a 60-Mbyte streaming 
tape drive, six serial ports, one parallel 


printer port, and an 85-, 180-, or 380- 
Mbyte unformatted hard disk drive. Soft¬ 
ware includes MS-DOS and a six-user 
Pick license. Prices range from $7,700 to 
more than $13,000. 

The AMS 1600 uses a 25-MHz 386- 
based CPU and comes with the same fea¬ 
tures as the AMS 1200. Prices range 
from $10,300 to around $21,000. 
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Midrange systems target 
Pick market 

Alpha Microsystems has announced a 
family of midrange business systems 
based on the Pick operating system, the 
8- to 160-user AMS 2000 Series. Models 
in the new series rely on Motorola’s 
68020 and 68030 processors. 

The AMS 2200 ranges in price from 
$19,750 to around $190,000. It comes 
with a 16.7- or 20-MHz 68020-based 
processor with 16 Kbytes of zero-wait- 
state cache and 2 Mbytes of ECC mem¬ 
ory. A base configuration includes a 1.2- 
Mbyte floppy disk drive, a magnetic tape 
subsystem, eight serial ports, one parallel 
port, a disk subsystem, and a 32-user 
Pick operating system license. 

The AMS 2600 costs from $39,500 to 
more than $360,000. It comes with a 20- 
MHz 68020-based processor or a 20- or 
25-MHz 68030-based processor. A base 
configuration includes 2 Mbytes of ECC 
memory, a 1.2-Mbyte floppy disk drive, 
a magnetic tape subsystem, 16 serial 
ports, one parallel port, a 390-Mbyte un¬ 
formatted disk subsystem, and a 64-user 
Pick operating system license. 

Both the AMS 2000 models are avail¬ 
able with a variety of options, including 
local area networking and communica¬ 
tions support through the company’s 
Common Network Architecture. 
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dV/dt accelerates 
hardware design 

Doctor Design claims that its dV/dt 
timing diagram editor software helps en¬ 
gineers speed up the hardware design 
and development process by allowing 
them to perform interactive digital de¬ 
sign “what if’ calculations. Designers 
can interactively vary clock speeds, 
logic types, memory speeds, and wait 
states. The software also provides auto¬ 
matic generation of timing diagram 
documentation. 

The IBM version runs on ATs and 
compatibles and PS/2 Models 20 to 30. 

It requires 640 Kbytes of memory; DOS 
3.0 or higher; a CGA, EGA, VGA, or 
Hercules graphics monitor or adapter; a 
Microsoft-compatible mouse; and an Ep¬ 
son MX or HP LaserJet or compatible 
printer. 

The Macintosh version runs on the 
Mac Plus, SE, SE/30, II, IIX, IICX, or 
IICI. It requires 1 Mbyte of memory and 
supports Chooser-selectable printers. 

Both versions of dV/dt cost $695. 
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1C Announcements 


Company, Model, Function Comments 


Analog Devices A 12-bit D/A converter with eight-deep FIFO memory, output buffer amp, and reference. Has a 

AD7848 42-ns min write-pulse width, a 4-|J,s settling time, a 250-kHz output update rate, and an on-chip 

DAC programmable status/control register. Comes in a 28-pin DIP, 40-terminal PLCC, or 40-termi¬ 

nal LCC. Cost (100s): $9.85-$38.55. 


Analog Devices 
AD1321/2 
Pin drivers 


C-Cube Microsystems 
CL550 

Image compressor 


FasMath 83S87 
Math coprocessor 


Pin drivers with a time less than 1.9-ns max to switch to high-impedance inhibit mode, discon¬ 
necting the device under test from the drive signal. Guaranteed max 200 nA leakage current. 
Come in a 16-lead surface-mount package. Cost (100s): start at $45 for 100-MHz AD1321 and 
$85 for 200-MHz AD 1322. 

A single-chip image compression processor that implements the proposed JPEG standard. 
Compresses still images (10-MHz CL550-10) or motion video (27-MHz CL550-27) by a fac¬ 
tor of 20. Also integrates interfaces and data tables. Comes in a 144-pin PGA (CL550-27) or 
144-pin quad flat pack (CL550-10). Cost (10,000s): $155 for CL550-27; $95 for CL550-10. 

A math coprocessor for the 80386SX processor. Has IEEE-754-1985 support. Software- and 
socket-compatible with Intel’s 80387SX. Three units: interface, execution, and control. Pro¬ 
vides eight data registers, a control register, and a status register. Comes in plastic and ceramic 
68-pin JLCCs. Cost: $579.99 (16 MHz); $639.99 (20 MHz). 


Micro Networks A sampling A/D converter with a 2-MHz min sampling rate, 12-bit resolution, and on-board 

MN6249 T/H amp. Combines the 400-ns MN5249 A/D and the 200-ns MN376 T/H in one package for 

Sampling ADC DSP. Comes in four models of different performance over three temperature ranges. Comes in 

a 40-pin DIP. Cost (100s): starts at $285 commercial, $497 prime grade, $571.50 Mil-Std-883. 


National Semiconductor 
NM4492WX, 
NM100492WX 
SRAMs 


A family of self-timed SRAMs with max access times from 5-10 ns. All have FIOOK I/O levels 
and come in 64-lead ceramic quad flat packs. NM4492W5 has a 5-ns access time; NM4492W7, 
7 ns; NM4492W10, 10 ns; NM100492W7, 7 ns; and NM100492W10, 10 ns. Cost (100s); $21o’ 
for 5-ns version; $150 for 7-ns version; $125 for 10-ns version. 


Newer Technology 
LaserWriter II SIMMs 
SIMMs 

Precision Monolithics 

DAC-8426 

DAC 


BPS81288P 

SRAM 


A line of 1-Mbytex8 SIMMs for the Apple LaserWriter II NTX printer. Allows the addition of 
up to 12 Mbytes of high-speed memory. Plug-in installation on the printer motherboard. Uses 
80-ns chip technology. Can be used with resident 256-Kbyte SIMMs. Cost: $235 (1 Mbyte). 

A quad 8-bit D/A converter with an internal lOV bandgap reference, a voltage-switched DAC, 
and output buffer amps. Operates from a 15V power supply at 180 mW. Pin-compatible with 
AD7226 sockets. Comes in 20-pin plastic and ceramic DIPs. Cost (100s): starts at $14.50 ex¬ 
tended industrial temperature range; $51 military. 

A 2-Mbit SRAM with memory interface logic and on-board capacitors. Organized 256Kx8 
bits. Uses a 5V power supply. Data retention voltage of 2V. Requires no clock or refresh. TTL- 
compatible inputs and outputs. Comes in a 32-pin DIP. Cost (100s): $180. 


S-MOS Systems A 4-Mbit mask ROM with an access time of 120 ns. Organized 524,288 words by 8 bits. Can op- 

SMM43400C erate on a single power source. TTL-compatible input and output ports with a three-state out- 

Mask ROM put. Requires no external clock. Comes in a 32-pin DIP. Cost (10,000s); $14; $7,500 for masks. 


Standard Microsystems A single-chip LAN controller for Arcnet. Has a zero-wait-state PC AT interface, 2Kx8 of on- 
COM90C66 chip dual-port RAM, software compatibility with the COM90C26 Arcnet controller, arbitra- 

Arcnet controller tion logic, and command chaining. Designed for compatibility with Arcnetplus when avail¬ 

able. Comes in an 84-pin PLCC. Cost (2,500s): $24.50. 


Teledyne Components 
TSC172/3 
PWM family 


Texas Instruments 
74ACT16245 
Bus transceiver 


A family of current-mode pulse-width modulators. Features user-programmable under/over 
voltage set points, under voltage interface signal, 1.5 mA typical supply current, 70-ns shut¬ 
down pin, independent and isolated power and control grounds, and linear timing ramp. Comes 
in 16-pin packages. Available in low and high speeds (400 KHz for TSC 172, 1 MHz for 
TWC172H). Cost (10,000s): $1.30 for TSC172CPE. 

A 16-bit bus transceiver, part of the ACL Widebus series. A TTL-compatible device with 
three-state outputs, has a flow-through architecture. Meets Jedec Standard 20.0 electrical 
specs for advanced CMOS logic. Comes in a shrink SOP. Cost (1,000s): $3.24. 
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Microsystem Announcements 


Company, Model. Function _ Comments _ B.S. No. 

Ampro Computers An AT-compatible 80386 single-board computer measuring 5.75x8 inches. Has a 20-MHz 135 

Little Board/386 80386 CPU with up to 4 Mbytes of RAM, multidensity floppy disk controller, dual RS-232-C 

SBC serial ports, parallel printer port, and optional SCSI interface. Cost (100s): $1,170 (0 RAM). 

Arcom Control Systems A 68020-based processor board with dual interfaces to VME and STE buses. Includes a socket 136 
VSC020T for the 68881 math coprocessor, up to 2 Mbytes of DRAM with 1 Mbyte dual-ported to the 

SBC VMEbus, 32 Kbytes of battery-backed SRAM dual-ported to the STEbus, two serial ports, and 

two EPROM sockets. Cost: from £1,095 (16-MHz 68020, 1 Mbyte DRAM). 


C&C Technology 

TVM-220 

SBC 


Computer Peripherals 
Golf 386 SX 
Portable computer 


Force Computers 
CPU-40, -41 
SBCs 


ICL Business Systems 
Models 50, 55 
PCs 


Intel 

System 520BX 
Multibus II system 


Mercury Computer 
Systems 
MC860 Series 
Attached processors 

Micro Signals 

DataMaster 

SBC 


A 68020-based single-board computer compliant with VMEbus Rev. C.l. Available at 16-, 137 

20-, 25-, or 33-MHz clock speeds. Includes 1 Mbyte of video DRAM. Comes with eight mem¬ 
ory sockets and two EEPROM sockets, two RS-232-C ports, and a parallel port. Cost: $3,175 
(16-MHz version). 

An 80386SX-based portable desktop computer, now available with a 100-Mbyte hard disk 138 
drive. Manufactured in cooperation with SMT Goupil. Has a 16-MHz 386SX CPU, 1 Mbyte of 
RAM expandable to 9 Mbytes, an on-board VGA controller, MS-DOS 4.1, supertwist LCD flat 
screen, and 101-key keyboard. Comes with carrying case. Cost: $7,190. 

Single-slot VMEbus boards based on the 68040 CPU at 24 or 33 MHz. Come with 4 or 16 139 

Mbytes of DRAM with parity (CPU-40), 4 Mbytes of SRAM (CPU-41), 32-bit DMA control¬ 
ler, two EPROM sockets, four serial channels, battery-backed 32-Kbyte SRAM, and a 68040 
version of the VMEPROM operating system. Sampling in the third quarter. 

PCs in the DRS family, based on the 80386SX microprocessor. Come with 1 Mbyte of RAM; 140 
20, 40, or 100 Mbytes of optional 3.5-inch hard disk storage; VGA graphics display adapters; 
and a 3.5-inch floppy disk drive. Model 50 has two expansion slots; Model 55 has four. Avail¬ 
able in the second quarter. Cost: starts at $2,250 for Model 50 and $2,915 for Model 55. 

A Multibus II system based on a single-board computer that includes a 386 microprocessor, 4 141 

Mbytes of memory, and an SCSI controller. Comes standard with a 150-Mbyte 5.25-inch tape 
drive, a 1.2-Mbyte floppy disk drive, and a 380-Mbyte hard disk drive. Has seven empty slots. 

Cost: $9,995 for hardware-only models. 

Attached processors based on the 40-MHz i860 RISC microprocessor. MC860VM has one 142 
i860 on a VMEbus 6U form-factor card; MC860VS has four i860s on a VMEbus 9U form-fac¬ 
tor card. MC860VM runs on Sun-3 and Sun-4 systems and 68020-based hosts running 
VxWorks with a pSOS kernel. Cost; starts at $11,900 with 2 Mbytes. 

A single-board computer with an 80C196 processor, floppy disk controller, parallel port, LCD 143 
interface, real-time clock, timers, 64 Kbytes of 16-bit RAM, 32 Kbytes of boot ROM, configur¬ 
able logic array, and support for A/D converters, timers, and serial port. Cost; $395; $95 for 96- 
DOS or bar-code software. 


Motorola 

MVME165 

SBC 

Myriad Solutions 

MC860 

i860 card 

Omnibyte 

OB68K/VME20 

SBC 


Symmetric Research 

SR-25MFP 

Coprocessor 


A 25-MHz single-board computer based on the 68040. Includes an MVME6000 with a master/ 144 
slave VMEbus interface, the MVSB2400 VSB chip with a master/slave VSB bus interface, and 
4-16 Mbytes of on-board DRAM. Available in June. Cost; $3,995 with 4 Mbytes of DRAM. 

A plug-in applications accelerator card based on the i860 microprocessor. Targets AT or com- 145 
patible PCs. Comes with 2 or 8 Mbytes of cached DRAM, expandable to 32 Mbytes. Has full AT 
Bus Master capability and a custom memory manager. Cost depends on configuration. 

A 68020 VME single-board computer with eight sockets for ROM, four of which can accept 146 
EEPROMs. Also has 32 Kbits of SRAM and eight sockets for SRAM. Features Omnimodule 
modular I/O. Comes standard with two RS-232-C serial ports and two 8-bit parallel ports. Im¬ 
plements the VTC VIC068. Cost (100s); $1,295; $45 for Omnimodules. 

A digital signal coprocessor board based on the AT&T DSP32C floating-point DSP chip. 147 

Comes with 640 Kbytes of on-board memory, dual porting, an assembler, a monitor debugger, 
math libraries, source code for software, demonstration programs, and a 32-bit bidirectional 
parallel port. Cost; $950; $300 for 640 Kbytes of 85-ns memory. 
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Users register needs with data engineers 


Ware Myers, Contributing Editor 

Marilyn Potes, Managing Editor 

Scientists want explanation-oriented 
programming. Industry needs a database 
system that evolves. And many users are 
looking forward to computer multimedia 
environments involving speech, image, 
language, and knowledge processing. 

These challenges to computer scien¬ 
tists — and especially to data engineers, 
who are concerned with the semantics 
and structuring of data in information 
systems — were posed by keynote speak¬ 
ers Kenneth G. Wilson, Dominique 
Laborde, and Raj Reddy at the Sixth 
International Data Engineering Confer¬ 
ence February 6-8 in Los Angeles. 

The conference was sponsored by the 
IEEE Computer Society. Joseph E. Urban 
of Arizona State University served as 
general chair; Ming T. (Mike) Liu of Ohio 
State University was program chair. 

Explanation orientation. When com¬ 
puter scientists move beyond object- 
oriented programming into explanation- 
oriented programming, that’s when sci¬ 
entists “will come running,” Wilson of 
Ohio State University said in his Febru¬ 
ary 6 keynote address. 

A 1982 Nobel laureate in physics who 
is active in supercomputing for scientific 
applications, Wilson said he’s often 
asked — and had been that morning — 
“Where are the scientists, and why are 
they still using Fortran?” Scientists have 
been told for years that they should 
switch from Fortran to something else, 
but Wilson said he’s never met a com¬ 
puter scientist who could say why in 
terms the scientist could relate to. 

“We may get the message out ourselves 
in the case of object-oriented program¬ 
ming,” Wilson said. He has 14,000 lines 
of C-F-F and is one of a small group of sci¬ 
entists who are actively working with ob¬ 
ject-oriented programming. 

This is a very exciting time for database 
research, Wilson said, and one reason for 
the excitement is the growth in thinking 
about object orientation and its addition 
to the general problem of dealing with 


conflicting principles of program organi¬ 
zation. But, he said, the single most im¬ 
portant thing to organize is not the func¬ 
tion or the data. It’s the explanation of the 
program. 

“A single line, preceded by double 
slashes or whatever, in the middle of the 
program prepared for some other pur¬ 
pose,” he said, is not the right way to 
achieve the explanation. From the scien¬ 
tist’s point of view, what’s needed is a 
programming framework where the ex¬ 
planation is prepared and modularized 
first — then the program appears after the 
double slashes. A Cornell University 
project led by David Gries is working on 
such a framework, and the name sug¬ 
gested for it is “explanation-oriented pro¬ 
gramming.” 

Wilson also noted that scientists are 
concerned that software problems — spe¬ 
cifically, the time needed to produce and 
test the code — will slow down their re¬ 
search efforts. This is one of the areas ad¬ 
dressed by the high-performance com¬ 
puting initiative, which is partly organ¬ 
ized around supercomputing and what 
have been called “grand challenges.” 

[The bill, currently in committee, was in¬ 
troduced last year by Senator Albert Gore 
(D-Tenn.) and Representative Doug 
Walgren (D-Pa.). Its software compo¬ 
nent earmarked $153 million for work on 
fundamental scientific problems identi¬ 
fied as “grand challenges.”] 

Wilson used work at the European 
Weather Center in Reading, England, to 
illustrate the complexities and computa¬ 
tional needs of one “grand challenge,” 
weather prediction. At the time of 
Wilson’s visit, the center’s analysis of 
800,000 atmospheric “chunks” was us¬ 
ing the full memory — and prodigious 
computing time — of a Cray X-MP/48 
supercomputer. Multiple forecasts sup¬ 
porting initial uncertainty and using two 
sets of data for each chunk would have 
kept a second computer busy. 

Each of the 800,000 chunks — 20 verti¬ 
cal layers of 200 segments around the 


equator and 200 segments from the North 
to South Poles — is characterized by five 
numbers representing wind velocity 
(three numbers), humidity, and air pres¬ 
sure. The size of the chunks is too large 
for accuracy, but the same calculations 
on segments reduced in size from 100 lon¬ 
gitude-latitude miles to one mile, with 
some increase in the number of layers, 
would require 10,000 times as much 
memory and one million times the com¬ 
puting power. 

But the real challenge, Wilson said, is 
algorithm development. Part of the plan 
behind the high-performance computing 
initiative is to push computing power from 
gigaflops to teraflops. The factor of 1,000 
improvement expected from the hard¬ 
ware is also needed from the algorithm. 

Scientists and computer scientists 
must “join forces,” he said, “so that the 
very best work in software enters scien¬ 
tific programming.” 

Evolving database. What industry 
needs is a database system designed to 
evolve as new developments come along, 
Laborde said in the second-day keynote 
address. Laborde is senior vice president 
for research and development of Computer 
Associates International, Garden City, 
New York. In the past database systems in 
general have not been designed to evolve. 

Hierarchical and network-type data¬ 
base systems date from the 1960s. These 
two and types known as inverted list and 
indexed sequential are used in most pro¬ 
duction systems still. Relational data¬ 
base systems developed by E.F. Codd in 
the early 1970s are used in information 
centers. The entity relationship principle 
underlies many data modeling and data 
administration systems. Executive infor¬ 
mation systems often use semantic-ori- 
ented query languages, but these lan¬ 
guages are generally limited to a specific 
domain. Still at the research level are 
more extended use of natural language, 
multimedia applications, and object-ori¬ 
ented systems. 
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Unfortunately these systems are in¬ 
compatible with each other, Laborde 
said. But they all exist out there. The di¬ 
lemma for industry is how to make them 
work together. One choice is for manage¬ 
ment information systems to be able to 
extract data from all kinds of database 
systems. The other choice is to rewrite ex¬ 
isting database systems into a single new 

The rewrite choice would take hun¬ 
dreds of programmers and many years. 

“If it took 10 years to build a system, it 
will probably take 10 years to do it again,” 
Laborde said. He believes the best solu¬ 
tion is MIS software able to work with all 
the multifaceted ways of handling data. 
Moreover, he believes that it is more eco¬ 
nomical for a software supplier such as 
Computer Associates to develop this sys¬ 
tem once, than for scores of Fortune 500 
companies each to develop their own sys¬ 
tem. 

At present, users’ existing programs 
issue a call to the users’ existing data¬ 
base, which returns the requested data. 
Laborde proposes what he calls an appli¬ 
cation transparency between a user’s ex¬ 
isting program and Computer Associ¬ 
ates’ own database system. When the user 
program issues a call to a database system 
such as VSAM, Total, or DL/1, the call is 
intercepted by the transparency layer. 


This layer emulates the request in Com¬ 
puter Associates’ database language and 
applies the request to the Computer Asso¬ 
ciates’ database. The data is returned to 
users through the transparency layer in 
the same form they would expect from 
their existing databases. 

SILK. “If there is one thing I would 
like you to remember from this talk, it is 
SILK.” That was Reddy’s injunction to 
the attendees in the concluding keynote 
speech. Reddy is director of the Robotics 
Institute at Carnegie Mellon University. 
SILK, he soon added, is an acronym that 
he invented, standing for Speech, Image, 
Language, and Knowledge processing. 

“These are the objects the database 
community will be dealing with in the 
1990s,” he predicted. “The problem is 
how to acquire, represent, store, and re¬ 
trieve such objects. What does it mean to 
index and search for relevant information 
in databases containing such objects?” 

The potential addition of these “multi- 
media environments” to the databases of 
the 1990s rests on the exponential rate of 
growth of data storage and processing 
capacity. In the past 20 years this growth 
rate has been about three orders of magni¬ 
tude, or around 3 percent per month com¬ 
pounded. 

“I have been told by people who study 


these matters that in the last 18 months 
they have been observing a compound 
growth rate of about 7 percent per 
month,” Reddy reported. “That means we 
should see another three orders of magni¬ 
tude in just 10 more years. The reason for 
this increased rate is the greater use of 
computer-aided tools in the design and 
development of these products.” 

This greatly increased capability makes 
it possible to store SILK data in raw form. 
What can you do with it? Well, Reddy 
cited one example: voice compression 
can delete pauses in speech and shorten 
long-held vowels. “You could listen to 
my one-hour talk after compression in 
htdf an hour without losing any content.” 

Speech recognition techniques could 
be used for indexing and searching a 
voice database. Even though recognition 
techniques are only 90 to 97 percent accu¬ 
rate, most of the key words would be 
picked up. In fact, approximate algo¬ 
rithms will be the wave of the future in 
multimedia databases, he said. You may 
not get perfect results, but with thousands 
of trillions of bits stored, there is no way a 
human being could look at all of it. 

A lot of research has already been done 
in the SILK technologies, Reddy stated. 
He invited the database community to get 
ready for the coming decade by looking 
into it. 


Database security needed 

As relations with the Soviet Union reach a more peaceful 
level, one might think that the need to protect databases would 
become less pressing. That might be true of military data to 
some degree (although the Defense Department doubtless 
disagrees), but panelists in the Security in Databases session 
pointed out that most databases, not only those in the military, 
contain sensitive medical, financial, personnel, or company- 
proprietary data. 

Organizations still want to protect their databases from un¬ 
authorized disclosure and modification, Bhavani Thuraising- 
ham of the Mitre Corp. said. They want mechanisms to ensure 
that users can acquire or modify only the information for which 
they are authorized. 

To detect intrusions, the database administrator uses a se¬ 
curity system to collect audit data. In the most sensitive situ¬ 
ations, this data can be analyzed continuously so that the sys¬ 
tem can respond in real time to an unauthorized invader, Ter¬ 
esa F. Lunt of SRI International said. In less sensitive applica¬ 
tions the security program might analyze the audit data off¬ 
line, after the tact. In either case the damage is assessed by 
subsequent analysis of the audit data. 

None of the security approaches is wholly successful at the 
present state of the art. How to detect intrusions is still a press¬ 
ing open question. “What aspects of user behavior are most in¬ 
dicative of intrusions?” Lunt asked. To help answer that ques¬ 
tion designers of security systems need many examples of ac¬ 


tual intrusions. But organizations have been reticent about 
sharing their experience. 

“We may not detect the most skilled penetrators,” Lunt con¬ 
cluded, “but we can increase the difficulty for the intruder." 

One of the threats to database integrity is malicious code, as 
Thomas Hinke of TRW called it. “If you don't know where the 
data comes from, then it may come from some malicious 
source.” Efforts to minimize exposure to malicious code re¬ 
duce fundamentally to two avenues: (1) ensure that no mali¬ 
cious code is introduced during either development or use of 
the system, and (2) compartmentalize the system so that the 
ability to modify unencrypted data is limited to a highly pro¬ 
tected compartment containing a minimum amount of code. 

Meantime, IFIP Working Group 11.3 has been focused on 
database security since 1986, according to its chair, Carl E. 
Landwehr of the Naval Research Laboratory. At present it is 
considering 16 issues, such as the performance implications 
of adding security requirements to database architectures. 

Interestingly, in seeking a concrete frame of reference in 
which to examine database security problems, the working 
group selected an integrated medical information system. The 
group sought an application that was not closely tied to a mili¬ 
tary environment and in which security requirements would be 
complex, but nevertheless intuitively apparent even to non¬ 
specialists. 

— Ware Myers 
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AIDA 89: Embedding AI systems 

Jorge L. Diaz-Herrera, George Mason University, AIDA 89 Conference Chair 


The AIDA conference series — the 
only conference emphasizing interaction 
between artificial intelligence and Ada, 
the US military’s standard programming 
language — has been progressively refin¬ 
ing a new research area: real-time AI 
computing. This was the theme of AIDA 
89, the fifth in the conference series, held 
November 16-17, 1989, in Reston, Vir¬ 
ginia, and cosponsored by George Mason 
University and the Institute for Defense 
Analyses, with the cooperation of the 
Software Productivity Consortium. 

What is real-time AI computing? 

The control of complex systems respond¬ 
ing to rapidly changing data is a critical 
bottleneck in applying knowledge-based 
techniques to embedded real-time com¬ 
puting. A real-time AI application must 
be integrated with existing conventional 
embedded software performing conven¬ 
tional real-time tasks. 

The problems facing designers of AI 
embedded applications are the same sort 
as those facing traditional real-time soft¬ 
ware engineers, but they are worsened by 
the nature of AI algorithms and the lack of 
AI real-time implementation tools. The 
technology for developing well-engi¬ 
neered real-time AI applications is not 
yet in place. 

Why Ada? Ada, not Lisp, should be the 
language of choice among AI implemen- 
ters. Jay Labhart and Kerry Williams of 
Merit Technology argued in their AIDA 
89 presentation. 

“Ada is or will be required as the deliv¬ 
ery language for embedded expert sys¬ 
tems and other target AI applications,” 
their report said, “and Ada is capable of 
directly supporting most current-genera¬ 
tion AI concepts, thereby enhancing the 
AI system through the incorporation of 
Ada’s modem software engineering 
qualities.” Traditional AI languages, the 
report added, “suffer from major draw¬ 
backs when implementing embedded 
mission-critical systems. Neither Lisp 
nor Prolog includes features for real-time 
embedded systems, and while C’s size 
and speed have made it successful in the 
implementation of high-performance AI 
systems, it lacks tme support for tasking 
and primitives for real-time operation.” 

Despite some current technological 
problems, Ada seems capable of support¬ 
ing most Al-specific requirements. A 
large percentage of AI code is procedural 
in nature and thus is best developed in a 
procedural language using “traditional” 
software engineering methods. 

Real time not necessarily fast. In his 
address, “Misconceptions about Real- 


Time Computing: A Serious Problem for 
Next-Generation Systems,” keynoter 
John Stankovic of the University of Mas¬ 
sachusetts, Amherst, dispelled an incor¬ 
rect and generalized notion that real time 
necessarily means fast. In fact, he ex¬ 
plained, there are “timing constraints” 
that, if not met, will make the system use¬ 
less. 

Stankovic described his Spring archi¬ 
tecture, developed, together with the 
proper scientific underpinnings, to sup¬ 
port real-time requirements and to 
achieve and guarantee results. The 
Spring kernel supports a distributed oper¬ 
ating system with real-time I/O and appli¬ 
cation processors for any node. 

At the core of Stankovic’s approach is 
the notion of a timeliness/worthiness 
spectrum (critical, essential, and nones¬ 
sential tasks) with an associated level of 
domain-dependent importance to influ¬ 
ence scheduling decisions. The kernel is 
being modified to support real-time AI, 
and a proposed extension includes the 
idea of incremental tasks, those that give 
a suboptimal answer quickly but keep 
working to improve the solution. 

A marriage of convenience, Claude 
Fomarino and Bertrand Neveu of INRIA 
claimed the lack of “a development meth¬ 
odology and software quality” in AI 
shops hampers the use of powerful, but 
inefficient, knowledge-based systems. 
Their object-oriented solution promises 
the best of both worlds by merging “Ada 
methodology, quality, and software engi¬ 
neering principles with environments, 
concepts, and tools created for AI upon 
Lisp dialects.” 

Fomarino and Neveu chose Ada for its 
high degree of production quality and its 
standardization level. They first pre¬ 
sented Ada-i-f, an Ada superset including 
classes and inheritance, which then de¬ 
veloped into ObjectivAda, adding “dy¬ 
namic management of polymorphic ob¬ 
jects” to the previous platform. 

As an example, they presented an ex¬ 
pert system shell. Rules were written in a 
special language, translated into an inter¬ 
mediate code, and added to the object 
base (semantic control), where they 
could be translated into Ada or Le_Lisp (a 
French dialect of Lisp). The inference 
engine was implemented in Ada. 

Fomarino and Neveu also described 
AdaLook, a graphical interactive envi¬ 
ronment for developing AI applications. 

Migration — Ada’s strong typing 
gets in the way. Strong typing is a major 
problem that has to be solved in translat¬ 
ing Pascal to Ada, Peggy Wright of Boe¬ 


ing reported. She also said, “Although 
Ada has well-established means for inter¬ 
facing with conventional code through 
the use of the pragma interface, this inter¬ 
face requires a hard-coded call to the par¬ 
ticular procedure.” 

Christine Kelly and Christopher Marsh 
of Mitre, along with Alain Jouchoux and 
Fred Lacy of the University of Colorado 
at Boulder, translated a prototype expert 
system for the Space Station Freedom 
from Lisp to Ada. The translation and re¬ 
hosting from a Symbolics machine to a 
VAX took only a short time. They used 
the Oasis package (operations and sci¬ 
ence instmment support) written in Ada 
at the University of Colorado. Another 
part of the system was implemented in C, 
which can coexist with Ada through the 
pragma interface. 

Kelly and her colleagues noted the lack 
of mature AI tools and methodologies in 
Ada, although there are many in Lisp. 

“But Oasis was flexible enough,” she 
said. “All our concerns related to losing 
the Lisp environment, which many con¬ 
sider synonymous with AI, were re¬ 
solved.” Ada’s strong typing did not 
cause “loss of flexibility” as they had 
feared. On the contrary, they found the 
Ada system “much easier to customize” 
than the Lisp prototype. 

Ada AI applications tend to be 
smaller. Richard McCabe and Craig 
Heartwell of Software Architecture and 
Engineering reported on ADS, the adap¬ 
tive diagnostic system designed to per¬ 
form fault isolation in the role of either an 
assistant or a self-sufficient diagnosti¬ 
cian for the Navy’s Integrated Diagnostic 
Support System. The system success¬ 
fully embedded AI techniques within 
more conventional software systems; 
they are not simply prototypes but will be 
deployed. According to McCabe and 
Heartwell, the current generation of Ada 
runtime systems — just beginning their 
second generation, whereas some Ada 
compilers are in their fourth — will have 
to improve to take advantage of the “great 
potential for parallelism in a tool like 
ADS.” 

Vicky Sivess of the University of 
Southampton reported on another appli¬ 
cation, a neural network toolkit using 
Ada. The tasking and generic facilities 
inherent in Ada “proved very suitable for 
the problem,” Sivess said. “The code 
turned out to be surprisingly short, so it 
was possible to take a more traditional AI 
prototyping approach.” 

Ada goes expert. Six papers focused 
on expert/rule-based system technology 
in embedded real-time environments. 
These included reports on the Helsinki 
Prolog System, an extensive integrated 
programming environment for Prolog 
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implemented in Ada, a compiler and a 
simulator/planner system for a compo¬ 
nent-oriented rule-based specification 
language for manufacturing control soft¬ 
ware, and the Ada Real-Time Inference 
Engine (ARTIE) to support advanced 
avionics AI requirements and developed 
from the Pascal Inference Engine. AR¬ 
TIE is currently hosted in a number of 
architectures, including Apollo, VAX, 
Sun, and Silicon Graphics. 

Performance: Firing 1,400 rules per 
second. ARTIE is capable of firing 1,400 
rules per second when run on a VAXsta- 
tion 3100, according to Boeing’s Wright. 
Frederick Buoni of the Florida Institute 
of Technology reported a 100-fold de¬ 
crease in runtime when matching rules 
were kept in a compiled form for his fuzzy 
expert-system shell. His Ada execution 
times were much slower, however, when 
compared to Turbo Pascal. He used the 
Janus Ada compiler for this comparison. 

Ada gets support from AI. Styleman, 
an expert style editor for Ada, was de¬ 
scribed by Viswa Santhanam of Boeing. 
This rule-based expert system checks for 
style infractions in Ada source code. Par¬ 
tial Metrics, Robert Reynolds’ project at 
Wayne State University, does reverse 


engineering (reverse compilation) to 
generate abstract plans from source Ada 
programs, thus acquiring (programming) 
planning knowledge to “suggest a sys¬ 
tematic way to approach chunking on a 
large scale.” The system, written in Lisp, 
runs on a TI Explorer. 

Real-time AI systems. “Little re¬ 
search has been done on AI systems work¬ 
ing in real-time,” said Jan Zytkow of 
George Mason University, who also 
served as AIDA 90 program chair, in 
opening the panel he chaired on real-time 
AI systems. But traditional approaches, 
such as that of Ada, are not the solution, 
Zytkow added. “Major problems are lan¬ 
guage independent and consist in adapt¬ 
ing the basic AI method of heuristic 
search to the requirements of real-time 
processing.” 

Another panelist, Jan Bergandy of 
Southeastern Massachusetts University, 
agreed that AI real time is “currently ex¬ 
panding to new ranges of applications,” 
but, he said, this expansion “is associated 
with the change of programming lan¬ 
guage from Prolog and Lisp to Ada.” 
These AI languages “offer no notion of 
time or space management.” 

Panelist Chuck Howell of Mitre sup¬ 
ported the idea that real-time AI is lan¬ 


guage independent, adding that “the im¬ 
plementation language clearly influ¬ 
ences what is easily expressed and what is 
difficult to implement. The characteris¬ 
tics of the particular compiler and run¬ 
time must also be taken into account for 
real-time systems of any sort.” 

Viswa Santhanam of Boeing addressed 
the issue of whether real-time AI systems 
could be built in Ada. He assumed a posi¬ 
tive answer to the basic question, “Can 
real-time AI systems be built?” Assum¬ 
ing also that such systems have been built 
in Lisp up to this point, he concluded “Ada 
has some deficiencies relative to Lisp.” 
According to Santhanam, “Ada does not 
have and cannot have the same develop¬ 
ment environment as Lisp” but “should 
do well in performance” as Ada compiler 
and runtime technologies mature. 

AIDA proceedings, 1986-1989, are 
available from George Mason Univer¬ 
sity, Dept, of Computer Science, 4400 
University Dr., Fairfax, VA 22030-4444, 
phone (703) 323-2713, fax (703) 323- 
2630, e-mail aida(ffigmuvax.gmu.edu. 

AIDA 90, to be held November 15-16 
in Reston, will look deeper into real-time 
AI computing (with or without Ada). For 
information, contact George Mason Uni¬ 
versity. 
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J.L. Wolf, D.M, Dias, and P.S, Yu, IBM TJ. Watson 
Research Center, U.S.A. 

Using Join Operations as Reducers in Distributed 
Query Processing 

M.S. Chen and P.S, Yu, IBM T.J. Watson Research 
Center, U.S.A. 

12:30 - 2:00 p.m. 

Lunch 

2:00 - 3:30 p.m. 

Session V: 

Parallel Algorithms 

Session Chair: Andreas Reuter, Stuttgart University, 

West Germany 

Efficient Parallel Algorithms for Functional 
Dependency Manipulations 
R. Sridhar and S.S, Iyengar, Louisiana State University, 
U.S.A. 

Parallel Handling of Integrity Constraints on 
Fragmented Relations 

P. Grefen and P.M.G. Apers, University of Twente, The 
Netherlands 

Voting Cla.ss — An Approach to Achieving High 
Availability for Replicated Data 
J. Tang, Memorial University of Newfoundland, Canada 
4:00 - 5:30 p.m. 

Session VI; 

Panel Discussions 

Key Directions in Parallelism and Di.stribution in 
l)ataba,se .Systems 

Panel Chairman: Umeshwar Dayal, Digital Equipment 
Corporation, U.S.A. 


WEDNESDAY, JULY 4_ 

9:00 - 10:30 a.m. 

Session VII; 

Distributed Systems 

Se.ssion Chair: Witold Staniszkis, CRAI, Poland 
Joyces-: Model and Language for Multi-Site Distributed 
Systems 

M.C. Franky, Universidad de los Andes, Colombia 

Concepts and Methods for the Optimisation of 

Distributed Data Processing 

S. Jablonski, T, Ruf, and H. Wedekind, University of 

Erlangen-Nuernberg, We.st Germany 

Towards an Efficient Management of Objeas in a 

Distributed Environment 

A.E. Habbash, J.B. Grim.son, and C. Horn, Trinity 

College, Ireland 

11:00 a.m.-12:30 p.m. 

Session Vni; 

Distributed Query Proce.ssing 

Session Chair: Arait Sheth, Bell Communications 

Research, U.S.A. 

Correcting Execution of Distributed Queries 
P. Bodrik and J. Pyra, Technical University of 
Nova Scotia, Canada, andJ.S. Riordon, 

Carleton University, Canada 

A Hierarchical Approach to Concurrency Control for 

Multidatabases 

A.K. Elmagarmid and Y, Leu, Purdue University, U.S.A. 
Semantic Outerjoin Optimization in Multidataba,se 
Systems 

A.L.P. Chen. Bell Communications Research. U.S.A, 

2:00 - 5:30 p.m. 

Tutorials 
Tutorial III: 

Heterogeneous Multidatabase Systems 
Witold A. Litwin, INRIA, France, and Marek E, 
Rusinkiewicz, University of Houston, U.S.A, 

Tutorial IV: 

Parallelism in Logit Databases 
Doug DeGroot, Texas Instalments. I'.S.A, 

IEEE COMPUTER SOCIETY 



acm« 
















GENERAL INEORMATION 


GENERAL CO-CHAIRPERSONS: 

Jane Crimson. Trinit)' College 
Sushil jajodia, George Mason Universitv' 

PROGRAM CO-CHAIRPERSONS: 

Rakesh Agrawal. IB.M Almaden 
David Bell, L'niversity of Lister 

TLTORIALS CHAIRPERSON: 

Bruce Hillyer, AT&T Bell Labs 

LOCAL ARRANGEMENTS CHAIRPERSON: 
Sean Baker, Trinity College 

PUBLICITY CHAIRPERSONS: 

John Hughes, University of Ulster 
Marek Rusinkiewicz, University of Hou.ston 

FINANCE CHAIRPERSON: 

Dudley Dolan, Trinity College 


ACCOMMODATIONS 


Accommodations are available in single rooms for 
delegates and accompanying persons on the college 
campus at S42 per night, including full Irish breakfa,st. 
All rooms are equipped with sinks and there are 
showers and toilets on each floor. Delegates who wish 
to reserve rooms at this facility nuust include name, 
arrival and departure information and a S-i2 deposit 
per person with the conference registration form. 

Delegates should contact Dublin Tourism directly at 
the following address for hotel information and 
reservations: 

Dublin Tourism 
13-14 Upper O'Connell Street 
Dublin 2, Ireland 
Fax 353-1-876275 
Phone 353-1-735209 


The .symposium will be held at Triniw College, 

Dublin. Trinin- is one of the oldest universities in the 
British Isles, founded in 1592 by Queen Elizalwh I, 

Set in attractive parkland and gardens, the college 
retains much of its ancient character and seclusion. Its 
modern conference facilities, allied to a long tradition 
of hospitality to distinguished visitors, make it an ideal 
location for the .symposium. The college is in the r eiy 
heart of Ireland s capital and is within walking 
distance of shops, museums, theatres, and the historic 
sites of Dublin. Ireland generally has a mild, 
temperate climate and the daytime temperature in July 
should be in the 15 -24 C range, falling 5 -10 at night. 


REGISTRATION 


Plea,se complete and mail this form to: 

Sean Baker, Local Arrangements Chair, DPDS-90, 

Irish Computer Society, Dundrum Castle, Ballinteer Road, Dublin l6, Ireland 
E-mail: baker@cs.tcd,ie Phone: -i 353-1-982692 Fax: + 353-1-987454 


Registration Fees 


Tutorials 

Please specify any special dietary requirements: 



_I _II _III _IV 


Tutorials 




Member 

SllO(S130) 



Non-member 

S135(S160) 

The tutorial registration fee is per tutorial. The 

(A) Total regi.stration: 

Student 

S75 

conference registration fee includes coffee breaks, 

conference, tutorials, banquet 



the Civic Reception on Tuesday evening, and one 


Conference 


copy of the proceedings. The numbers in 


Member 

S225(S270) 

parentheses indicate the fees for late registration. 

(B) Total deposit for 

Non-member 

S270 (5335) 

after June 6,1990. Payment by bankers' draft, 

on-campus accommodations 

Student 

570(SlOO) 

drawn on a U.S. bank, in U.S. dollars only. 




Indicate tutorials and circle appropriate fees. 


Banquet 



(C) Total amount enclo,sed (A+B) 

Member 

540 



Non-member 

540 

Number of banquet tickets required_ 


Student 

540 


Bank draft number 


Affiliation, 

Addre.ss_ 


Arrival Date_ Departure Date 

Telephone_ 


li:i;i:-(;s/A(:.\1/IK:s/ICS .Memliership Numlx'r. 




































CALL FOR PAPERS 


® Supercomputing 90: Nov. 12-16, 1990, 
New York City. Cosponsor: ACM. Sub¬ 
mit five copies of paper by Apr. IS, 1990, to 
D.V. Pryor, Supercomputing Research Center, 
17100 Science Dr., Bowie, MD 20715, phone 
(301) 805-7407, e-mail pryor@super.org. 

t^^IEEE Workshop on the Management 
of Replicated Data: Nov. 7-9, 1990, 
Houston. Sponsor: IEEE Technical Commit¬ 
tee on Operating Systems. Submit eight copies 
of position statement by Apr. 15,1990, to 
Jehan-Francois Paris, Computer Science 
Dept., Univ. of Houston, Houston, TX 77204- 


3475, phone (713) 749-3943, e-mail paris@ 
cs.uh.edu; or Luis-Felipe Cabrera, IBM Al- 
maden Research Center, 650 Harry Rd., MC 
K55/803, San Jose, CA 95120-6099, phone 
(408) 927-1838. 

Cl 90,1990 Int’l Symp. on Computa¬ 
tional Intelligence: Sept. 24-28, 1990, 
Milano, Italy. Sponsors: ACM, F.I.S. Cassa di 
Rosp. o. PC. Submit five copies of paper by 
Apr. 20,1990, to Nick Cercone, Computer Sci¬ 
ence Dept., Simon Fraser Univ., Burnaby, BC, 
Canada V5A 1S6, phone (604) 291-4588, fax 
(604) 291-4045, e-mail nick%cs.sfu.ca@ 


sfu.bimet; or Francesco Gardin, AIS, Via 
Rombon 11, 20124 Milano, Italy, phone 39 (2) 
264-0197, fax 39 (2) 264-10744. 

14th Western Educational Computing 
Conf.: Nov. 15-16, 1990, Irvine, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Submit two copies of paper by Apr. 
21, 1990, to Oliver Seely, Jr., California State 
Univ. at Dominguez Hills, Chemistry, 1000 E. 
Victoria St., Carson, CA 90747. 

1990 IEEE Workshop on VLSI Signal Pro¬ 
cessing: Nov. 7-9, 1990, San Diego, Calif. 


Call for papers and referees for Computer 


Experimental Research in Computer Architectures has 
been selected as the theme for the January 1991 edition. 

The purpose of this special issue is to focus on the place of 
experimental research in computer architecture and perfor¬ 
mance measurement. 

Submitted articles must not have been previously published 
or currentiy submitted for publication elsewhere. Each manu¬ 
script shouid be no more than 32 typewritten, double-spaced 
pages long, including ali figures and references. The cover 
page of each submittal should include the article's title, the au¬ 
thor’s full name, affiliation, complete physical and electronic 
addresses, telephone number, plus a list of keywords identify¬ 
ing the central issues of the manuscript’s contents. Refer¬ 
ences should be limited to 12. 

Submittals and questions should be directed to guest editor 
Yaie N. Patt, Department of Electrical Engineering and Com¬ 
puter Science, University of Michigan, Ann Arbor, Ml 48109- 
2122, phone (313) 936-1602, e-mail patt@eecs.umich.edu. 

A 300-word abstract should be sent to Patt by April 20, 

1990, and eight copies of the full manuscript must be submit¬ 
ted to him by June 1,1990. Authors will be notified of accep¬ 
tance by August 15,1990. The final version of the manuscript 
is due no later than October 1,1990. 

Those interested in serving as referees for this special issue 
should send a note indicating their technical interests and 
qualifications to Patt at the above address or to Bruce D. 
Shriver, Editor-in-Chief, Computer, the University of South¬ 
western Louisiana, PO Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Bitnet 
shriver@usl.edu 

For more details, see p. 112 of the March issue. 

Computer-Based Medical Systems has been selected as 
the theme for the March 1991 edition. The scope and breadth 
of computer-based medical systems research and commer¬ 
cialization has changed markedly over the past decade. What 
was only recently performed through an electromechanical 
design may now have upwards of 20 processors and 400,000 


lines of code. Regulatory agencies are concerned that the addi¬ 
tion of software may make a product inherently unreliable while 
the manufacturer may contend just the opposite. Thus, partici¬ 
pants in the field debate the strategies to assure safety and effi¬ 
cacy and the use of metrics to measure the same. 

This special issue will be devoted to examining the driving 
forces in the field, as well as historical directives and predictions j 

of future directives. Manuscripts of a tutorial, descriptive, case- ; 

study, applications-oriented or pedagogic nature are immedi- i 

ately sought in the following and related fields: 

• Clinical assessment and risk evaluation ' 

• Implantable systems 

• Diagnostic systems ' 

• Imaging systems i 

• Life-support systems 

• Artificial intelligence 

• Neural networks 

Preference will be given to articles that delineate specific appli¬ 
cations of the following processes in the development of the proj¬ 
ect or product described in the manuscript: 

• Regulations 

• Complexity metrics i 

• Standards i 

• Quality assurance j 

• Hazard assurance 

• Failure modes and criticality effects analysis 

• Electromagnetic compatibility 

Manuscripts must not have been previously published or cur¬ 
rently submitted for publication elsewhere. Each manuscript 
should be no more than 32 typewritten, double-spaced pages 
long, including ali figures and references. Each submittal should 
contain the title of the article, the full name of the author(s), 
affiliation(s), complete postal and electronic address(es), tele¬ 
phone number(s), a 300-word abstract, and a list of keywords 
identifying the central issues of the manuscript’s contents. The 
final manuscript should have approximately 7,500 words and no 
more than 12 references. 
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Submit three copies of extended summary or 
complete paper by Apr. 23,1990, to Patti Fen- 
stermacher, AT&T Bell Labs, 1243 S. Cedar 
Crest Blvd., Allentown, PA 18103, e-mail 
psf@aloft.att.com. 


boundary scan in JTAG/IEEE standards. Sub¬ 
mit six copies of full manuscript by Apr. 27, 
1990, to Karen Cullen, Kluwer Academic Pub¬ 
lishers, 101 Philip Dr., Norwell, MA 02061, 
phone (617) 871-6300, fax (617) 871-6528. 


frameworks, and databases. Submit paper by 
Apr. 30, 1990, to Evangelos Simoudis, A1 Ap¬ 
plications Group, DEC, 290 Donald Lynch 
Blvd., MS DLB5-2/B4, Marlboro, MA 01752, 
phone (508) 490-8141. 


ICCAD 90, IEEE IntT Conf. on Com- 
puter-Aided Design: Nov. 11-15, 1990, 
Santa Clara, Calif. Cosponsor: IEEE Circuits 
and Systems Society. Submit 12 copies of ab¬ 
stract and paper by Apr. 27,1990, to MP Asso¬ 
ciates, 7490 Clubhouse Rd., Suite 102, Boul¬ 
der, CO 80301, phone (303) 530-4562 or 4333. 

Second Int’l Conf. on Algebraic and Logic 
Programming: Oct. 1-3, 1990, Nancy, 

France. Submit five copies of paper by Apr. 27, 
1990, to Wolfgang Wechler, TU Braun¬ 
schweig, Theoretische Informatik, Postfach 
3329, D-3300 Braunschweig, West Germany, 
e-mail wechler@infbs.uucp. 

J. Electronic Testing: Theory and Appli¬ 
cations plans a special issue in January 1991 on 


ICCV 90, Third Int’l Conf. on Com- 
puter Vision: Dec. 4-7, 1990, Osaka, Ja¬ 
pan. Submit four copies of paper by Apr. 30, 
1990, Saburo Tsuji, Osaka Univ., Control En¬ 
gineering Dept., Toyonaka, Osaka 560, Japan, 
e-mail tsuji@tsuji.ce.osaka-u.ac.jp. 

CASE 90, Fourth Int’l Workshop on 
Computer-Aided Software Engineer¬ 
ing: Dec. 5-8, 1990, Irvine, Calif. Sponsors: 
Int’l Workshop on CASE et al. Submit six cop¬ 
ies of position paper by Apr. 30,1990, to 
Wayne Stevens, IBM, 472 Wheelers Farms 
Rd., Milford, CT 06460-2757, phone (203) 
783-4432, fax (203) 783-7488. 


Third Int’l Symp. on Artificial Intelligence: 
Oct. 22-26, 1990, Monterrey, N.L. Mexico. 
Sponsors: ITESM (Inst. Tecnologico y de Es- 
tudios Superiores de Monterrey) et al. Submit 
five copies of paper by Apr. 30, 1990, to Hugo 
Terashima, Centro de Inteligencia Artificial, 
ITESM, Sue. de Correos “J”, C.P. 64849 Mon¬ 
terrey, N.L. Mexico, phone 52 (83) 58-2000, 
fax 52 (83) 58-0771. 


Second IEEE Symp. on Parallel and 
Distributed Processing: Dec. 10-12, 
1990, Dallas. Sponsor: IEEE Computer Soci¬ 
ety Dallas Section. Submit seven copies of pa¬ 
per by May 1,1990, to Behrooz Shirazi, Com¬ 
puter Science and Engineering Dept., South¬ 
ern Methodist Univ., Dallas, TX 75275, phone 
(214) 692-2874, e-mail shirazi%smu.uucp@ 


Submittals and questions should be directed to John M. Long, 
Surgery and Computer Science, Univ. of Minnesota, 2701 Uni¬ 
versity Ave. SE, Suite 201, Minneapolis, MN 55414, phone (612) 
627-4850, fax (612) 625-3206, Bitnet hvm6006@umnacca; or 
Timothy J. Kriewall, Sarns/3M Health Care Group, 6200 Jackson 
Rd., Ann Arbor, Ml 48103, phone (313) 971-3517, ext. 276, fax 
(313) 663-5062. 

I The abstract is due by June 1,1990, and eight copies of the full 

manuscript must be submitted by July 1,1990. Authors will be no¬ 
tified of acceptance by September 15,1990. The final version of 
the manuscript is due no later than December 1,1990. 

If you are willing to serve as a referee for this special issue, send 
a note with a list of your technical interests and qualificafions to 
Bruce D. Shriver, Editor-in-Chief, Computer, the University of 
Southwestern Louisiana, PO Drawer 42730, Lafayette, LA 
70504-2730, phone (318) 231-5811, fax (318) 265-5472, Internet 
shriver@usl.edu 

I Computer Generated Music has been selected as the theme 

for the July 1991 issue. Applications of computer techniques to 
music are as old as modern computer science and were foreseen 
by Ada Loveiace a century ago. The emphasis of the contributions 
sought here, however, should be on pleasurable outputs. While 
theoretical studies in musicology or new techniques for the syn¬ 
thesis of sounds have great scientific relevance, both from a com¬ 
putational and from a musical standpoint, they are too often re¬ 
served for specialists and have little appeal to the general, unso- 
! phisticated public. Computer music has reached the point where 
it no longer has to be relegated to acoustic labs and research cen- 
! ters, but produces a musical quality that can be appreciated by 
’ everyone and which evokes feelings and sensitivities like more 
i conventional types of music. 

i While any submission can be accepted in principle, those proj- 

I ects whose results can be heard and which exhibit a certain sen- 
\ suality will be preferred. The manuscripts should describe highly 
I original projects, contain at least one chapter explaining the goals 
and the techniques used, and include one equally important sec¬ 
tion describing the audio results and discussing possible short¬ 
comings or improvements. 

The issue will be devoted to examining the driving forces in the 
field from a computational standpoint, assessing the limits of 
computer music in the general field of music, and discussing fu¬ 
ture desirable directions. We are currently considering having 
musical outputs from computers, synthesizers, etc., made avail- 

_ 


able and published with an audio cassette enclosed with the 
magazine. 

All areas of computer music will be considered, such as but 
not limited to: 

• Algorithms for composition, harmonization, theme im¬ 
provisation 

• Tools for analytical and musicological studies and for 
playing 

• Novel sound synthesis techniques to overcome sound 
dryness and software to model perception 

• Use of digital electronics and MIDI for artistic purposes 

• Non-Western music 

Manuscripts should be no more than 32 typewritten, double¬ 
spaced pages long, including all figures and references. Ar¬ 
ticles must not have been previously published or submitted 
elsewhere, although portions may have been published in 
conferences and audio results may have been played in lec¬ 
tures. 

Each manuscript should have a cover page that includes the 
title of the article, full name(s) and affiliation(s) of the 
author(s), complete postal and electronic address(es), tele¬ 
phone number(s), a 300-word abstract, and a list of keywords, 
especially for music, that identify the central issues of the 
manuscript's content. The final manuscript should have ap¬ 
proximately 7,500 words and no more than 12 references. 

The abstract is due by August 30,1990, and four copies of 
the full manuscript and four audio cassettes are due by Octo¬ 
ber 30,1990. Notification of acceptance is set no later than 
December 31,1990, and the final version of the manuscript is 
due no later than March 30,1991. 

Submissions should be sent to Denis Baggi, Istituto Dalle 
Molle per Stud! sull' Intelligenza Artificiale, Corso Elvezia 36, 
6900 Lugano, Switzerland, phone 41 (91) 56 15 78, Europe e- 
mall denis%idsia.uucp@chx400.switch.ch, US e-mail 
baggi@berkeley.edu 

If you are willing to review articles, please send a note to 
Denis Baggi or Bruce Shriver, editor-in-chief of Computer 
with a list of your technical interests and qualifications. 
Shriver’s address is Bruce D. Shriver, University of South¬ 
western Louisiana, PO Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Internet 
shriver@usl.edu 
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uunet.uu.net; or Hal Sudborough, CS Dept., 
Univ. of Texas at Dallas, PO Box 830688, 
Richardson, TX 75083, phone (214) 690-2184. 


11th Real-Time Systems Symp.: Dec. 

5-7, 1990, Orlando, Fla. Sponsor; IEEE 
Computer Society Technical Committee on 
Real-Time Computing. Submit five copies of 
paper by May 1,1990, to Jane W.S. Liu, 1304 
W. Springfield Ave., Computer Science Dept., 
Univ. of Illinois, Urbana, IL 61801-3082, 
phone (217) 333-0135, e-mail janeliu@ 
cs.uiuc.edu. 


AIRIES 90, AI Research in the Environ¬ 
mental Sciences Workshop: Sept. 25-27, 
1990, Montreal, Que., Canada. Cosponsors; 
Univ. of Quebec at Montreal, Centre Re- 
searche Informatique de Montreal. Submit ab¬ 
stract for oral presentation, poster presenta¬ 
tion, or demonstration by May 1, 1990, to 
Rosemary M. Dyer, GL/LYP, AIRIES 90, Air 
Force Geophysics Lab, Hanscom Air Force 
Base, MA 01731, fax (617) 377-4498. 


MNEMO 90 IntT Symp.: Oct. 1990, Varna, 
Bulgaria. Sponsor: TIZUMD section on Mne- 
mology and Bionic Artificial Intelligence. 
Submit a one-page abstract on human memory 
modeling and simulation by May 1, 1990, and 
complete text by Aug. 1,1990, to Simeon J. 
Mrchev, MNEMO 90, Georgi Dimitrov blvd., 
45, ap. 28, 6003 Stara Zagora, Bulgaria, phone 
(042) 3-50-86. 


Ninth National Conf. on EDP System and 
Softvrare Quality Assurance: Oct. 22-24, 
1990, Washington, DC. Sponsor: Data Pro¬ 
cessing Management Assoc. Submit abstract 
by May 1, 1990, to US Professional Develop¬ 
ment Inst., EDP System and Software Quality 
Assurance, 1734 Elton Rd., Suite 221, Silver 
Spring, MD 20903-1733, phone (301) 445- 
4400, fax (301) 445-5722. 


Int’l Workshop on VLSI for Artificial Intel¬ 
ligence and Neural Networks: Sept. 5-7, 

1990, Oxford, England. Submit abstract by 
May I, 1990, to Jose G. Delgado-Frias, Electri¬ 
cal Engineering Dept., SUNY, Binghamton, 
NY 13901, phone (607) 777-4806, e-mail 
delgado@bingvaxu.cc.binghamton,edu. 


1990 IFIP-IEEE IntT Workshop on Defect 
and Fault Tolerance in VLSI Systems: Nov. 
5-7, 1990, Grenoble, France. Submit 17 copies 
of extended summary by May 1,1990, to Gab¬ 
riel Saucier, Inst. National Polytechnique de 
Grenoble/CSI, 46, avenue Felix-Viallet, 

38031 Grenoble Cedex, France, phone (33) 76- 
57-46-87, fax (33) 76-50-23-21 (for authors in 
Europe); or Tulin E. Mangir, TRW, 1 Space 
Park, R2/2036, Redondo Beach, CA 90278, 
phone (213) 813-3894, fax (213) 813-3709. 

Progress in Neural Networks plans the third 
volume its series. Submit one-page abstract by 
May 1,1990, to Omid M. Omidvar, Univ. of the 
District of Columbia, Computer Science 
Dept., 4200 Connecticut Ave. NW, Washing¬ 
ton, DC 20008, phone (202) 282-7345, fax 
(202) 282-3677, e-mail oomidvar@ 
udcvax.bitnet. 

AI 90, Australian Joint Artificial Intelli¬ 
gence Conf.: Nov. 21-23, 1990, Perth, West¬ 


ern Australia. Sponsor; Australian Computer 
Society. Submit paper by May 11,1990, to Les 
Kitchen, Univ. of Western Australia, Com¬ 
puter Science Dept., Nedlands, Western Aus¬ 
tralia, 6009, phone 61 (9) 380-2281, e-mail 
ai90@wacsvax.oz.au. 


Second Computer Society 
IntT Conf. on Tools for Artificial Intel¬ 
ligence: Nov. 6-9, 1990, Washington, DC. Co¬ 
sponsors: Rutgers Univ. et al. Submit four cop¬ 
ies of panel proposal, tutorial proposal, and full 
paper by May IS, 1990, to W.T. Tsai, Com¬ 
puter Science Dept., 4-192 EE/CS Bldg., 200 
Union St. SE, Univ. of Minnesota, Minneapo¬ 
lis, MN 55455, phone (612) 625-6371. 

Visualization 90: Oct. 23-26, 1990, San 
Francisco, Calif. Submit four copies of 
paper by May 15,1990, to Arie Kaufman, 
Computer Science Dept., SUNY at Stony- 
brook, Stonybrook, NY 11794-4400, phone 
(516) 632-7441. 

EuroVHDL 90, First European Work- 
ing Conf. on VHDL Methods: Sept. 4-7, 
1990, Marseille, France. Cosponsors: AFCET 
et al. Submit paper by May 15,1990, to AFCET 
Service des Congres, EuroVHDL 90, 156 Bid. 
Pereire, 75017 Paris, France, phone 33 (1) 47- 
66-24-19, fax 33 (1) 42-67-93-12. 


ICARCV 90, IntT Conf. on Automation, 
Robotics, and Computer Vision: Sept. 18-21, 
1990, Singapore. Cosponsors: IEEE Sin¬ 
gapore Chapter et al. Submit extended sum¬ 
mary and abstract by May 15,1990, to Dinesh 
P. Mital, ICARCV 90, School of Electrical and 
Electronic Engineering, Nanyang Technologi¬ 
cal Inst., Nanyang Ave., Singapore 2263, Re¬ 
public of Singapore, phone (65) 660-5399. 


10th Conf. on Foundations of Software 
Technology and Theoretical Computer Sci¬ 
ence: Dec. 17-19, 1990, Bangalore, India. Sub¬ 
mit six copies of full paper by May IS, 1990, to 
K.V. Nori, TRDDC, 1 Mangaldas Rd., Pune 
411 001, India, phone (212) 662-453. 


Second SIAM Conf. on Linear Algebra in 
Signals, Systems, and Control: Nov. 5-9, 
1990, San Francisco, Calif. Sponsor: Society 
for Industrial and Applied Mathematics. Sub¬ 
mit abstract of paper or poster by May 16, 
1990, to SIAM, 3600 University City Science 
Center, Philadelphia, PA 19104-2688, phone 
(215) 382-9800, fax (215) 386-7999, e-mail 
siam@wharton.upenn.edu. 


Sixth Computer Security Applica- 
tions Conf.: Dec. 3-7, 1990, Tucson, 
Ariz. Sponsors: American Society for Indus¬ 
trial Security et al. Submit five copies of paper 
or panel proposal by May 18,1990, to Ronald 
A. Gove, Booz-Allen and Hamilton, 4330 
East-West Highway, Bethesda, MD 20814, 
phone (301) 951-2395, e-mail gove@dock 
master.ncsc.mil. 


(3^ ISth Conf. on Local Computer Net- 
works: Oct. 1-3, 1990, Minneapolis, 
Minn. Submit five copies of paper by May 22, 
1990, to Marc Cohn, Advanced Development 
Div., Raychem Corp., 300 Constitution Dr., 
Menlo Park, CA 94025-1164, phone (415) 
361-3902, fax (415) 361-6099. 


24th Asilomar Conf. on Signals, Sys- 
terns, and Computers: Nov. 5-7, 1990, 
Pacific Grove, Calif. Sponsors: Naval Post¬ 
graduate School et al. Submit three copies of 
abstract and extensive summary by June 1, 
1990, to Frederic J. Harris, Electrical and Com¬ 
puter Engineering Dept., San Diego State 
Univ., San Diego, CA 92182-0190, phone 
(619) 594-6162. 


croarchitecture: Nov. 27-29, 1990, Orlando, 
Fla. Cosponsor: ACM. Submit five copies of 
full paper by June 15,1990, to Chris Pa- 
pachristou. Case Western Reserve Univ., 
Computer Engineering and Science Dept., 
Cleveland, OH 44106, phone (216) 368-5277, 
e-mail cap@alpha.ces.cwru.edu; or Vicki Al¬ 
lan, Utah State Univ., Computer Science 
Dept., Logan, UT 84321-4205, phone (801) 
750-2022, e-mail allanv@usu.bitnet. 

1990 IEEE Workshop on Languages 
and Architectures for Automation: 
Dec. 19-21, 1990, Honolulu, Hawaii. Spon¬ 
sors: Pacific IntT Center for High Technology 
Research et al. Submit five copies of paper by 
June 30,1990, to D.Y.Y. Yun, Univ. of Ha¬ 
waii, 711 Kapiolani Blvd., Suite 200, Hon¬ 
olulu, HI 96813-5249, phone (808) 539-1532, 
fax (808) 941-1399. 

Seventh IntT Conf. on Data Engineer- 
ing: Apr. 8-12, 1991, Kobe, Japan. Sub¬ 
mit five copies of paper by July 1,1990, to Nick 
J. Cercone, Center for Systems Science, Simon 
Fraser Univ., Burnaby, B.C., Canada, V5A 
1S6, (604) 291-3229, e-mail Nick@ 
CS.SFU.CA. 

IEEE Trans. Computers plans a special 
issue on protocol engineering. Submit 
six copies of manuscript by July 1,1990, to 
Ming T. (Mike) Liu, CIS Dept., Ohio State 
Univ., 2036 Neil Ave., Columbus, OH 43210- 
1277, phone (614) 292-1837. 

Fourth CSI/IEEE IntT Symp. on VLSI 
Design: Jan. 5-8, 1991, New Delhi. 
Sponsors: Computer Society of India et al. 
Submit six copies of paper by July 15,1990, to 
L.M. Patnaik, Computer Science and Automa¬ 
tion, Indian Inst, of Science, Bangalore 
560012, India, phone 91 (812) 342-451; or 
A.D. Singh, Electrical and Computer Engi¬ 
neering Dept., Univ. of Massachusetts, 
Amherst, MA 01003, phone (413) 545-0188. 

^ CAIA 91, Seventh IEEE Conf. on Arti- 
ficial Intelligence Applications: Feb. 
24-28, 1991, Miami Beach, Fla. Submit paper 
by Aug. 31,1990, to Tim Finin, Center for Ad¬ 
vanced Information Technology, Unisys, 70E 
Swedesford Rd., PO Box 517, Paoli, PA 19301, 
phone (215) 648-2840. 

ICSE 13,13th IntT Conf. on Software 
Engineering: May 13-16, 1991, Austin, 
Texas. Cosponsor: ACM. Submit eight copies 
of paper by Sept. 14,1990, to David Barstow, 
Schlumberger Lab for Computer Science, PO 
Box 200015, Austin, TX 78720-0015. 
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CALENDAR 


April 1990 


Applications of Artificial Intelligence 
VIII, Apr. 15-18, Orlando, Fla. Cospon¬ 
sor; SPIE. Contact Mohan M. Trivedi, Univ. of 
Tennessee, Electrical and Computer Engineer¬ 
ing, Ferris Hall, Knoxville, TN 37996-2100, 
phone (615) 974-5450. 


1990 Technical Symp. on Optical Engineer¬ 
ing and Photonics in Aerospace Sensing, 
Apr, 16-20, Orlando, Fla. Sponsor: SPIE. Con¬ 
tact Int’l Society for Optical Engineering, PO 
Box 10, Bellingham, WA 98227-0010, phone 
(206) 676-3290. 


13th IEEE Workshop on Design for 
Testability, Apr. 17-20, Vail, Colo. 
Contact T.W. Williams, IBM, PO Box 1900, 
Dept. 67A/021B, Boulder, CO 80301-9191, 
phone (303) 924-7692. 


10th European Meeting on Cybernetics and 
Systems Research, Apr. 17-20, Vienna, Aus¬ 
tria. Sponsor: Austrian Society for Cybernetic 
Studies. Contact Robert Trappl, Cybernetics 
and Artificial Intelligence Dept., Univ. of Vi¬ 
enna, Freyung 6/2, A-lOlO Vienna, Austria, 
phone 43 (222) 5353-2810. 


First Int’l Conf. on Systems Integra- 
tion, Apr. 23-26, Morristown, N.J. 
Sponsor: New Jersey Inst, of Technology. 
Contact Peter A. Ng, Inst, for Integrated Sys¬ 
tems Research, Computer and Information 
Science Dept., New Jersey Inst, of Technol¬ 
ogy, Newark, NJ 07102, phone (201) 596- 
3387, fax (201) 596-5777, e-mail ng_p@ 
vienna.njit.edu. 


1990 Eastern Multiconf., Apr. 23-26, Nash¬ 
ville, Tenn. Sponsor: Society for Computer 
Simulation. Contact SCS, PO Box 17900, San 
Diego, CA 92117-7900, phone (619) 277-3888. 


First European Conf. on Computer Vision, 
Apr. 23-27, Antibes. France. Sponsor: INRIA. 
Contact C. Juncker, Inst. Nat’l de Recherche en 
Informatique et en Automatique, Bureau des 
Relations Exterieures, Sophia Antipolis, 2004, 
Route des Lucioles, 06565 Valbonne Cedex, 
France, phone 33 (93) 65-78-60. 

COIS 90, Conf. on Office Information 

Systems, Apr. 25-27, Cambridge, Mass. 
Cosponsor: ACM. Contact Robert B. Allen, 
Rm. 2A-367, Bellcore, 444 South St., Morris¬ 
town, NJ 07960-1910, phone (201) 829-4280 
or 4315. 


SETA 1, First IntTSymp. on Environ- 
sS? ments and Tools for Ada, Apr. 30-May 
2, Redondo Beach, Calif. Cosponsor: ACM. 


In the accompanying Calendar, the IEEE Computer Society logo identifies 
the conferences the society is sponsoring and participating in. Other confer¬ 
ences of interest to our readers, as weli as their sponsors, are aiso listed. 

For inclusion in Cali for Papers or Caiendar, submit information at least six 
weeks before the month of publication (i.e., for the June 1990 issue, send infor¬ 
mation for receipt by April 15,1990) to Chuck Governale, Calendar Dept., Com¬ 
puter, PO Box 3014, Los Alamitos, CA 90720-1264. 


Contact Stowe Boyd, Meridian Software Sys¬ 
tems, 23141 Verdugo Dr., Suite 105, Laguna 
Hills, CA 92653, phone (714) 727-0700, ext. 
222; or Dewayne E. Perry, AT&T Bell Labora¬ 
tories, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2529. 

11th Structured Development Forum, Apr. 
30-May 3, San Diego, ciif. Contact Gail 
Phipps or Judith G. Hays, Computer Sciences 
Corp., 1321 Mercedes Dr., Hanover, MD 
21076, phone (301) 859-0400. 


May 1990 


Workshop on Measurement and Mod- 
eling of Computer Dependability, May 
1-2, El Segundo, Calif. Contact Daniel 
Siewiorek, School of Computer Science, Car¬ 
negie Mellon Univ., Pittsburgh, PA 15213- 
3890, phone (412) 268-2570, e-mail dps@ 


a.gp.ci 




lAAI 90, Second Conf. on Innovative Appli¬ 
cations of Artificial Intelligence, May 1-3, 
Washington, DC. Sponsor: American Assoc, 
for Artificial Intelligence. Contact AAAI, 445 
Burgess Dr., Menlo Park, CA 94025, phone 
(415) 328-3123. 

24th Carnahan Conf. on Security Technol¬ 
ogy, May 2-4, Lexington, Ky. Contact Glenna 
Vickers, Office of Engineering Continuing 
Education, Univ. of Kentucky, 305 Slone 
Bldg., Lexington, KY 40506-0053, phone 
(606) 257-4296. 

21st Pittsburgh Conf. on Modeling and 
Simulation, May 3-4, Pittsburgh. Sponsors: 
Univ. of Pittsburgh et al. Contact William G. 
Vogt or Marlin H. Mickle, Modeling and Simu¬ 
lation Conf., 348 Benedum Engineering Hall, 
Univ. of Pittsburgh, Pittsburgh, PA 15261. 


10th IEEE Symp. on Mass Storage Sys- 
terns. May 6-10, Monterey, Calif. Con¬ 
tact Bernard T. O’Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268. 


1990 IEEE Symp. on Research in Secu- 
rity and Privacy, May 7-9, Oakland, 
Calif. Contact Deborah Cooper, Unisys, 5731 
Slauson Ave., Culver City, CA 90230, phone 
(213) 338-3727. 

AISIG 90, Fifth AI Systems in Govern- 
ment Conf., May 7-11, Washington, 

DC. Cosponsors: Mitre et al. Contact Barry G. 
Silverman, Inst, for AI, George Washington 
Univ., 2021 K St., Suite 710, Washington, DC 
20006, phone (202) 676-5112. 

Fourth Int’l Symp. on Knowledge Engineer¬ 
ing, May 7-11, Barcelona, Spain. Sponsor: 
Madrid Polytechnic Univ. Contact Jose R. 
Chelala, ISKE, Alvarez de Baena, 3-2, 28006 
Madrid, Spain. 

CompEuro 90, IEEE Int’l Conf. on 
Computer Systems and Software En¬ 
gineering, May 8-10, Tel Aviv. Cosponsors: 
IEEE Region 8, IEEE Israel Section, IEEE 
Computer Society Israel Chapter. Contact 
CompEuro 90 Conf. Secretariat, c/o ORTRA, 

2 Kaufman St., PO Box 50432, Tel Aviv 615(K), 
Israel, phone 972 (3) 664-825, fax 972 (3) 660- 
952. 


JISI 90, Computer Science and Deci- 
sion Support, May 9-11, Tunis, Tunisia. 
Contact M. Ben Ahmed, ENSI, 16 rue Bolo, 
Montplaisir 1002, Tunis Le Belvedere, Tuni¬ 
sia, phone 216 (1) 780-394. 

^ Seventh IEEE Workshop on Reai- 
Time Operating Systems and Soft¬ 
ware, May 10-11, Charlottesville, Va. Co¬ 
sponsor; Office of Naval Research. Contact 
Robert P. Cook, Computer Science Dept., 

Univ. of Virginia, Thornton Hall, Charlottes¬ 
ville, VA 22903, phone (804) 924-7605. 


First IEEE Int’l Conf. on Applications of In- 
dustriai Electronics Systems, May 13-17, 
Jerusalem, Israel. Sponsor: IEEE Israel Sec¬ 
tion. Contact Moshe Harpaz, Kibbutz Ein- 
Carmel, D.N. Hof Carmel 30860, Israel, phone 
(972) 4-844410. 


1990 IEEE Int’l Conf. on Robotics and Auto¬ 
mation, May 13-18, Cincinnati, Ohio. Spon- 
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sor: IEEE Robotics and Automation Society. 
Contact Robotics and Automation Conf., PO 
Box 3216, Silver Spring, MD 20918, (301) 
434-1990. 

Workshop on Interconnections 
Within High-Speed Digital Systems, 
May 14-16, Santa Fe, N.M. Cosponsors: IEEE 
Communications Society et al. Contact Randal 
Moulic, IBM Research Div., PO Box 704, Rm. 
H4-A04, Yorktown Heights, NY 10598, phone 
(914) 789-7321. 

1990 Society for Information Display Int’l 
Symp., May 14-18, Las Vegas. Contact How¬ 
ard L. Funk, IBM Corp., 10/641 3B-60, Old Or¬ 
chard Rd., Armonk, NY 10504, phone (914) 
765-6409. 

QW 90, Quality Week 1990, May 15-18, San 
Francisco, Calif. Contact Mary Anne Francis 
or Rita Bral, Software Research Inc., 625 Third 
St., San Francisco, CA 94107, phone (415) 
957-1441, (800) 942-SOFT, fax (415) 957- 
0730. 

43rd SPSE Conf., May 20-25, Rochester, 

N.Y. Sponsor: SPSE (Society for Imaging Sci¬ 
ence and Technology). Contact Michael M. 
Shahin, Xerox Corp., Webster Research Cen¬ 
ter, 800 Phillips Rd., 0114-38D, Webster, NY 
14580, phone (716) 422-2011. 

Conf. on Artificial Intelligence 
for Space Applications, May 22-23, 
Huntsville. Ala. Cosponsors: IEEE Computer 
Society Huntsville Chapter et al. Contact Con¬ 
tinuing Education Div., Univ. of Alabama in 
Huntsville, Tom Bevill Center 285-1, Hunts¬ 
ville, AL 35899, phone (800) 448-4035 or 
(205) 895-6372. 

First Conf. on Visualization in Bio- 
medical Computing, May 22-25, At¬ 
lanta. Cosponsors; Nat’l Science Foundation 
et al. Contact Norberto Ezguerra, Bioengineer¬ 
ing Center, Georgia Tech, Atlanta, GA 30332, 
phone (404) 894-7026 or 3964. 

SIGMetrics 90, May 22-25, Boulder, Colo. 
Sponsor: ACM. Contact Gary J. Nutt, Univ. of 
Colorado, Boulder, CO 80301; or Herb 
Schwetman, MCC, 3500 W. Balcones Center 
Dr., Austin, TX 78759, phone (512) 338-3428. 

20th Int’l Symp. on Multiple-Valued 
Logic, May 23-25, Charlotte, N.C. Con¬ 
tact George Epstein, Computer Science Dept., 
Univ. of North Carolina at Charlotte, 214 Ken¬ 
nedy Bldg., Charlotte, NC 28223, phone (704) 
547-4566; or Carolyn F. Blalock, Office of 
Continuing Education, Univ. of North Caro¬ 
lina at Charlotte, Charlotte, NC 28223, phone 
(704) 547-4861. 

1990 American Control Conf., May 23-25, 

San Diego, Calif. Sponsor; American Auto¬ 
matic Control Council. Contact Dagfmn 
Gangsaas, Boeing Advanced Systems, PO Box 
3707, MS 33-12, Seattle, WA 98124-2207, 
phone (206) 393-6852. 

17th Int’l Symp. on Computer Archi- 
tecture. May 28-31, Seattle. Cosponsor; 
ACM. Contact Jean L. Baer or Larry Snyder. 


Univ. of Washington, Computer Science 
Dept., FR-35, Seattle, WA 98195, phone (206) 
543-1695. 

Euro ASIC 90, May 28-June 1, Paris. 

Contact Gabriele Saucier, Inst. Naf 1 
Polytechnique de Grenoble/CSI, 46, avenue 
Felix Viallet, 38931 Grenoble Cedex, France, 
phone 33 (1) 76-57-46-87. 

ICDCS 10,10th Int’l Conf. on Distrib- 

uted Computing Systems, May 28- 
June 1, Paris. Cosponsor: INRIA. Contact R. 
Popescu-Zeletin, GMD-FOKUS, Harden- 
bergplatz 2, D-1000 Berlin 12, West Germany, 
phone 49 (30) 25499-206; Jack Stankovic, 
Computer and Information Science Dept., 
Univ. of Massachusetts, Amherst, MA 01003, 
phone (413) 545-0720; or ICDCS 10, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 


June 1990 


CBMS 90, Third IEEE Symp. on Com- 
puter-Based Medical Systems, June 3- 
6, Chapel Hill, N.C. Cosponsor: IEEE Engi¬ 
neering in Medicine and Biology Society. Con¬ 
tact James N. Brown, Jr., Research Triangle 
Inst., 3040 Cornwallis, Research Triangle 
Park, NC 27709, phone (919) 541-9675. 

Spring Comdex, June 3-6, Atlanta. Contact 
Interface Group, 300 First Ave., Needham, 

MA 02194, phone (617) 449-6600. 

IEEE Infocom 90, Ninth Conf. on 
Computer Communications, June 3-7, 
San Francisco. Cosponsor: IEEE Communica¬ 
tions Society. Contact Infocom 90, IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

Lies 90, Fifth Symp. on Logic in Com- 
puter Science, June 4-7, Philadelphia. 
Contact Albert Meyer, Computer Science Lab, 
545 Technology Square, NE 43-315, Cam¬ 
bridge, MA 02139, phone (617) 253-6024. 

Int’l Workshop on Rapid System 
Prototyping, June 5-7, Triangle Re¬ 
search Park, N.C. Contact Kenneth Anderson, 
Siemens Corporate Research, 755 College Rd. 
E., Princeton, NJ 08540, phone (609) 734- 
6550. 

IFIP Workshop on Design and Test of 
ASICs, June 11-12, Hiroshima, Japan. 
Cosponsors: Information Processing Society 
of Japan et al. Contact Kozo Kinoshita, Hiro¬ 
shima Univ., 1-1-80 Higashisendacho, Naka- 
ku, Hiroshima-shi 730, Japan, phone 81 (87) 
249-9150. 

19th Mumps Users’ Group Meeting, June 
11-15, Orlando, Fla. Contact Mumps Users’ 
Group, 4321 Hartwick Rd., Suite 100, College 
Park, MD 20740, phone (301) 779-6555. 


(3m Computer Security Foundations III, 
June 12-14, Franconia, N.H. Contact 
Tom Haigh, SCTC, 2855 Anthony Lane South, 
St. Anthony, MN 55418, phone (612) 782- 
7145. 

(3^ ICPR 90,10th Int’l Conf. on Pattern 
Recognition, June 17-21, Atlantic City, 
N.J. Contact Herbert Freeman, CAfP Center, 
605 Hill, Rutgers Univ., New Brunswick, NJ 
08903, phone (201) 932-4208. 

(3^ EDFT, Seventh European Workshop 
on Design for Testability, June 18-20, 
Segovia, Spain. Contact T.W. Williams or C. 
Lopez Barrio, IBM, PO Box 1900, Dept. AJA/ 
021B, Boulder, CO 80301-9191, phone (303) 
924-7692. 

DAC 90, 27th ACM/IEEE Design 
NSX Automation Conf., June 25-29, 
Orlando, Fla. Contact Pat Pistilli, MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boulder, 
CO 80301, phone (303) 530-4333. 

3^ I"*’! Symp. on Fuzzy Approach to Rea- 
nAz soning and Decision Making, June 25- 
29, Bechyne, Czechoslovakia. Cosponsor: 

Int’l Fuzzy System Assoc. Contact Vilem No¬ 
vak, Minin Inst., Czechoslovakia Academy of 
Sciences, A. Rimana 1768, 70800 Ostrava- 
Poruba, Czechoslovakia. 

3^ FTCS 20, 20th Int’l Symp. on Fault- 
Tolerant Computing, June 26-28, 
Newcastle upon Tyne, England. Cosponsors; 
Centre for Software Reliability, British Com¬ 
puter Society, lEE. Contact Neil Speirs, Com¬ 
puting Lab, Univ. of Newcastle upon Tyne, 
Newcastle upon Tyne, NEl 7RU, UK, phone 
44 (91) 232-8511. 

(3^ ^(xl 90, Computer Graphics Int’l 
1990, June 26-30, Kent Ridge, Singa¬ 
pore. Sponsors: Computer Graphics Society, 
Inst, of Systems Science, Singapore. Contact 
Juzar Motiwalla, CGI 90, ISS, Nat’l Univ. of 
Singapore, Heng Mui Keng Terr., Kent Ridge, 
Singapore 0511, phone (65) 772-2075. 

(3^ Rocky Mountain Conf. on Artifi- 
cial Intelligence, June 28-30, Las 
Cruces, N.M. Cosponsors: ACM et al. Contact 
Paul McKevitt, Computing Research Lab, 

Dept. 3CRL, Box 30001, New Mexico State 
Univ., Las Cruces, NM 88003-0001, phone 
(505) 646-5109, fax (505) 646-6218, Internet 
paul@nmsu.edu. 


July 1990 


(3m Second Int’l Symp. on Databases in 
Parallel and Distributed Systems, July 
2-4, Dublin, Ireland. Cosponsor: ACM. Con¬ 
tact Rakesh Agrawal, AT&T Bell Labs, Rm. 
3D450, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2250; or David Bell, 
Inst, of Informatics, Univ. of Ulster, Jordans- 
town. County Antrim, Northern Ireland 
BT370QB. phone (0232) 365-131. 
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Second Int’l Conf. on Economics and 
Artincial Intelligence, July 2-6, Paris. 
Sponsor: AFCET. Contact J-L. Le Moigne, 
GRASCE, Univ. Aix Marseille III, 3, ave. 
Robert Schuman, 13628, Aix en Provence, 
France; or P. Bourgine, 26, rue St. Louis, 
78000, Versailles, France. 

SPAA 90, Second ACM Symp. on Par- 
ailel Algorithms and Architecture, 
July 2-6, Crete, Greece. Cosponsor: ACM. 
Contact Tom Leighton, MIT, Cambridge, MA 
02139, phone (617) 253-3662. 

WCCE 90, Fifth World Conf. on Com- 
puters in Education, July 9-13, 

Sydney, Australia. Cosponsors: IFIP et al. 
Contact WCCE 90, PO Box 319, Darlinghurst, 
NSW 2010, Australia, phone (612) 211-5855. 

Third Int’l Conf. on Industrial and 
Engineering Applications for AI and 
Expert Systems, July 15-18, Charleston, S.C. 
Cosponsors: ACM et al. Contact Moonis Ali, 
Univ. of Tennessee Space Inst., MS 15, Tulla- 
homa, TN 37388, phone (615) 455-0631. 


August 1990 


SIGGraph 90,17th Conf. on Com- 
puter Graphics and Interactive Tech¬ 
niques, Aug. 6-10, Dallas. Sponsor: ACM. 
Contact Assoc, for Computing Machinery, 11 
W. 42nd St., New York, NY 10036, phone 
(212) 869-7440. 


16th Int’l Conf. on Very Large Data 
Bases, Aug. 13-16, Brisbane, Australia. 
Contact David Reiner, Lotus Development, 1 
Canal Park, Cambridge, MA 02141, phone 
(617) 577-8500. 

Hot Chips 2 Symp., Aug. 20-21, Santa 
Clara, Calif. Contact Hasan S. 

AlKhatib, EECS Dept., Santa Clara Univ., 
Santa Clara, CA 95053, phone (408) 554-4485, 
fax (408) 554-5475, e-mail halkhatibt® 
scu.edu. 


September 1990 


ISPRS Commission V Symp., Close- 
Range Photogrammetry Meets Ma¬ 
chine Vision, Sept. 3-7, Zurich. Cosponsor: 
Int’l Society for Photogrammetry and Remote 
Sensing et al. Contact Armin Gruen, Inst, of 
Geodesy and Photogrammetry, ETH- 
Hoenggerberg, CH-8093, Zurich, Switzer¬ 
land, phone 41 (1) 377-3051. 

EuroVHDL 90, First European Work- 
N8? ing Conf. on VHDL Methods, Sept. 4- 
7, Marseille, France. Cosponsors: ACM et al. 
Contact Petra Michel, Siemens, A.G. Dept. 
ZFEISEAI, Otto Hahn Ring 6, Munich 83, 
West Germany. 


April 1990 



National University of Singapore 
Department of Electrical Engineering 


The Department of Electrical Engineering invites applications for teaching and re¬ 
search positions from candidate's with a PhD degree in one of the following areas: 

Computer Communications 
Computer Systems 
Image Processing/Computer Vision 

Gross annual emoluments range as follows: 

Research Fellow S$44,860 - 64,200 

Lecturer S$53,l 60 - 64,200 

Senior Lecturer S$58,680 -100,310 

Associate Professor S$88,650 -122,870 

(US$1.00 = S$l.87 approximately) 


The commencing salary will depend on the candidate's qualifications, experience 
and the level of appointment offered. 

Leave and medical benefits will be provided. Depending on the type of contract 
offered, other benefits may include: provident fund benefits or an end-of-contract 
gratuity, a settling-in allowance of S$1,000 or S$2,000, subsidized housing at nom¬ 
inal rentals ranging from S$100 to S$216 p.m., education allowance for up to three 
children subject to a maximum of S$10,0(X) per annum per child, passage assistance 
and baggage allowance for the transportation of personal effects to Singapore. Staff 
members may undertake consultation work, subject to the approval of the Univer¬ 
sity, and retain consultation fees up to a maximum of 60% of their gross annual 
emoluments in a calendar year. 

The Electrical Engineering Department has currently an academic staff of 48 with 
18 laboratories, all of which have excellent facilities for teaching and research. Its 
Semiconductor Laboratory has a Riber 32P Molecular Beam Epitaxy System and 2 
liquid phase epitaxy systems for research into III-V compound devices, while its 
Microelectronics Laboratory has facilities for fabricating ICs in 4-micron poly-gate 
single metal CMOS technology. A wide range of computing resources are avail¬ 
able, including numerous PCs, SUN Sparcstations, Microvaxes, and HP9(X)0 Series 
300s. The University Computer Centre operates an IBM3081KX2, and is acquiring 
a high-speed campus-wide network directly linking the staff's PCs (now provided 
to every staff member) to the various computing resources, including 2 super¬ 
computers based in the nearby Science Park. A number of large-scale research pro¬ 
jects are in progress, including an optical LAN joint effort with Singapore Telecoms 
and a project to develop VLSI design tools jointly with Chartered Semiconductors. 
Application forms and further information on terms and conditions of service may 
be obtained from: 


The Director 
Personnel Department 
National University of 
Singapore 

10 Kent Ridge Crescent 
Singapore 0511 


The Director 

North America Office 

National University of Singapore 

55 East 59th Street 

New York, NY 10022, USA 

Tel: (212) 751-0331 


Enquiries may also be send through BITNET to: PERSDEPT @ NUSVM, or 
through Telefax: (65) 7783948. 
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ASAP 90, Int’l Conf. on Application- 
Specific Array Processors, Sept. 5-7, 
Princeton, N.J. Cosponsor: Princeton Univ. 
Contact S.Y. Kung, Electrical Engineering 
Dept., Princeton Univ., Princeton, NJ 08544, 
phone (609) 258-3780. 

ITC 90, Int’l Test Conf., Sept. 10-12, 
Washington, DC. Cosponsor: IEEE 
Philadelphia Section. Contact Donald 
Denburg, AT&T Bell Labs, 1247 S. Cedar 
Crest Blvd., Allentown, PA 18103; or ITC, 
1201 Sussex Turnpike, Suite 101, PO Box 264, 
Mt. Freedom, N1 07970, phone (201) 895- 
5260. 

IEEE Conf. on Managing Expert Sys- 
tem Programs and Projects, Sept. 10- 
12, Washington, DC. Sponsor: IEEE Com¬ 
puter Society Technical Committee on Expert 
Systems. Contact Jay Liebowitz, Management 
Sciences Dept., George Washington Univ., 
Washington, DC, phone (202) 994-6969. 

ICCD 90, IEEE Int’l Conf. on Com- 
puter Design: VLSI in Computers and 
Processors, Sept. 16-19, Cambridge, Mass. 
Contact Edward M. Middlesworth, Hewlett- 
Packard, Bldg. 25U, PO Box 10350, Palo Alto, 
CA 94303-0867, phone (415) 857-5485; or 
ICCD 90, IEEE Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

ASIC 90, Third IEEE ASIC Seminar 
and Exhibit, Sept. 17-21, Rochester, 
N.Y. Cosponsors: IEEE Rochester Section, 
ACM. Contact Kenneth Hsu, Rochester Inst, of 
Technology, Computer Engineering Dept., 
Rochester, NY 14623, phone (716) 475-2655; 
or Lynne Engelbrecht, 170 Mt. Read Blvd., 
Rochester, NY 14611, phone (716) 328-2310, 
fax (716) 436-9370. 

EP 90, Electronic Publishing 90, Sept. 
18-20, Gaithersburg, Md, Sponsor: Nat’l 
Inst, of Standards and Technology. Contact Pe¬ 
ter R. King, Computer Science Dept., Univ. of 
Manitoba, Winnipeg, Manitoba, Canada R3T 
2N2, phone (204) 474-9935. 

Cl 90,1990 Int’l Symp. on Computa- 
tional Intelligence, Sept. 27-29, Mi¬ 
lano, Italy. Sponsors: ACM, F.l.S. Cassa di 
Rosp. o. PC. Contact Giorgio Valle, Universita 
Milano. Dip. Scienze Della Informazione, Via 
Moretto 20133, Milano, Italy, phone 39 (2) 
757-5228, fax 39 (2) 761-10556, e-mail 
valle@imiucca.bitnet 


Sponsor: IPSJ. Contact Takuma Yamamoto, NTnvpmhor 1 QQfl 
Fujitsu, 3-14-1 Hiyoshi, Kohoku-ku, Yokoha- 
mashi, Japan. 


October 1990 


Conf. on Local Computer 
Networking, Oct. 1-3, Minneapolis, 
Minn. Contact Marc Cohn, Advanced Devel¬ 
opment Div., Raychem Corp., 300 
Constitution Dr., Menlo Park, CA 94025- 
1164, phone (415) 361-3902, fax (415) 361- 
6099. 

Infojapan 90, Int’l Conf. on Informa- 
tion Technology, Oct. 1-5, Tokyo. 


Sixth Int’l Conf. on the Application of 
Standards for Open Systems Intercon¬ 
nection, Oct. 2-4, Gaithersburg, Md. Cospon¬ 
sor: Nat’l Inst, of Standards and Technology. 
Contact Brenda Gray, NIST/OSI, Rm. B217, 
Bldg. 225, Gaithersburg, MD 20899, phone 
(301) 975-3664. 

Frontiers 90, Third Symp. on Fron- 
tiers of Massively Parallel Computa¬ 
tion, Oct. 8-10, College Park, Md. Cosponsor: 
NASA Goddard Space Flight Center. Contact 
Johanna Weinstein, Frontiers 90, UMIACS, 
Univ. of Maryland, A.V. Williams Bldg., Col¬ 
lege Park, MD 20742, phone (301) 454-1808. 

Future Trends 90, Workshop on Fu- 
ture Trends of Distributed Computing 
Systems, Oct. 8-10, Cairo. Contact Stephen S. 
Yau, Univ. of Florida, CIS Dept., Rm. 301, 
Gainesville, FL 32611, phone (904) 335-8006. 

Ninth Symp. on Reliable Distributed 
Systems, Oct. 9-11, Huntsville, Ala. 
Contact Raif M. Yanney, TRW, MS DH2/ 

2328, 1 Space Park, Redondo Beach, CA 
90278, phone (213) 764-6033. 

Third Fall VHDL Users’ Group Meet- 
ing, Oct. 21-24, Redondo Beach. Calif. 
Contact Rachel Rusting, Intermetrics, 733 
Concord Ave., Cambridge, MA 02138, phone 
(617) 661-1840. 

OOPSLA 90, Fifth Conf. on Object- 
vS/ Oriented Programming Systems, Lan¬ 
guages, and Applications, Oct. 21-25, Ot¬ 
tawa, Canada. Cosponsor: ACM. Contact As¬ 
soc. for Computing Machinery, 11 W. 42nd St., 
New York, NY 10036, phone (212) 869-7440. 

FOCS, 31st Foundations of Computer 
Science, Oct. 22-24, St. Louis, Mo. Con¬ 
tact Christos Papdimitriou, Computer Science 
Dept., Univ. of California at San Diego, La 
Jolla, CA 92093, phone (619) 534-2086. 

JCIT 5, Fifth Jerusalem Conf. on In- 
formation Technology, Oct. 22-25, 
Jerusalem, Israel. Sponsor: Information Proc¬ 
essing Assoc, of Israel. Contact Abraham 
Peled, IBM T.J. Watson Research Center, PO 
Box 704, Yorktown Heights, NY 10598. 

Visualization 90, Oct. 23-26, San Fran- 
cisco. Contact Bruce Brown, Oracle 
Corp., 20 Davis Dr., Belmont, CA 94002, 
phone (415) 598-3628. 

NACLP 90, 1990 North American 
Conf. on Logic Programming, Oct. 28- 
Nov. 1, Austin, Texas. Cosponsor: ACM. Con¬ 
tact Carlo Zaniolo, MCC, 3500 W. Balcones 
Center Dr., Austin, TX 78759, phone (512) 
338-3442. 

Compsac 90, 14th Int’l Computer 
Software and Applications Conf., Oct. 
31-Nov. 2, Chicago. Contact Ifay F. Chang, 

Rm. 1B28, IBM T.J. Watson Research Center, 
PO Box 714, Yorktown Heights, NY 10595, 
phone (914) 789-7825. 


14th SCAMC, 1990 Symp. on Com- 
puter Applications in Medical Care, 
Nov. 4-7, Washington, DC. Cosponsors: 
George Washington Univ. Medical Center et 
al. Contact SCAMC — Office of CEM, George 
Washington Univ. Medical Center, 2300 K St. 
NW, Washington, DC 20037, phone (202) 
994-8928. 

24th Asilomar Conf. on Signals, Sys- 
terns, and Computers, Nov. 5-7, Pacific 
Grove, Calif. Sponsors: Naval Postgraduate 
School et al. Contact George M. Dillard, Naval 
Ocean Systems Center, San Diego, CA 92152- 
5000, phone (619) 553-2478. 

Intelligent Robotic Systems; Design 
and Applications, Nov. 6-7, Philadel¬ 
phia. Sponsor: SPIE. Contact Mohan M. 
Trivedi, Univ. of Tennessee, Electrical and 
Computer Engineering, Ferris Hall, Knox¬ 
ville, TN 37996-2100, phone (615) 974-5450. 

TAI 90, Second Computer Society 
^=7 Int’l Conf. on Tools for Artificial Intel¬ 
ligence, Nov. 6-9, Washington, DC. Cospon¬ 
sors: Rutgers Univ. et al. Contact Nikolas G. 
Bourbokis, George Mason Univ., ECE Dept., 
Fairfax, VA 22030, phone (703) 425-3930. 

IEEE Workshop on the Management 
vSiZ of Replicated Data, Nov. 7-9, Houston. 
Sponsor: IEEE Technical Committee on Oper¬ 
ating Systems. Contact Jehan-Francois Paris, 
Computer Science Dept., Univ. of Houston, 
Houston, TX 77204-3475, phone (713) 749- 
3943, e-mail paris@cs.uh.edu; Luis-Felipe 
Cabrera, IBM Almaden Research Center, 650 
Harry Rd., MC K55/803, San Jose, CA 95120- 
6099, phone (408) 927-1838. 

ICCAD 90, IEEE Int’l Conf. on Com- 
puter-Aided Design, Nov. 11-15, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Society. Contact Pat Pistilli, MP As¬ 
sociates, 7490 Clubhouse Rd., Suite 102, Boul¬ 
der, CO 80301, phone (303) 530-4562 or 4333. 

Supercomputing 90, Nov. 12-16, New 
York City. Cosponsor: ACM. Contact 
Joanne L. Martin, IBM T.J. Watson Research 
Center, PO Box 218, Route 134, Yorktown 
Heights, NY 10698, phone (914) 945-3285, e- 
mail Jlmart@ibm.com: or Supercomputing 90, 
IEEE Computer Society, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 

Seventh Governor’s Symp. on High 
Technology, Nov. 13-15, Kauai, Hawaii. 
Sponsor; State of Hawaii. Contact William M. 
Ball, State of Hawaii, 300 Kahelu St., Suite 35, 
Mililani, HI 96789, phone (808) 625-5293. 

PRICAI 90, Pacific Rim Int’l Conf. on 
Artificial Intelligence 90, Nov. 14-16, 
Nagoya-shi, Aichi, Japan. Sponsor: Japanese 
Society for Artificial Intelligence et al. Con¬ 
tact Teruo Fukumura, Inter Group Corp., Aka- 
saka Yamakatsu Bldg., 8-5-32 Akasaka, Mi- 
nato-ku, Tokyo 107, Japan, phone (03) 479- 
5535. 
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CALL FOR PAPERS AND PARTICIPATION 


VLSI DESIGN 

’91 

THE FOURTH CSI/IEEE 
INTERNATIONAL SYMPOSIUM 
ON VLSI DESIGN 


Hyatt Regency, New Delhi, India 

January 5-8,1991 

In Cooperation with: 


jm) IEEE COMPUTER SOCIETY 

Technical Committees on Design Automation and VLSI 

IEEE CIRCUITS AND SYSTEMS SOCIETY 


THE INSTITUTE OF ELECTRICAL 

AND ELECTRONICS ENGINEERS, INC. 


Sponsored by. 


COMPUTER SOCIETY OF INDIA (CSI) 


DEPARTMENT OF ELECTRONICS (GOVERNMENT OF INDIA) 


The symposium is a forum for engineers and researchers to present and discuss various 
aspects of VLSI design. The four-day program will consist of regular paper sessions, 
posters, tutorials, and industrial CAD exhibits. There will be enough opportunities for 
informal exchange of ideas. The papers will be published as a hard-cover book that will 
be available at the symposium. 

TOPICS OF INTEREST (Partial List): CAD/CAE Systems, High Level Synthesis, Logic 
Synthesis, Fault Modeling, Test Generation, Design For Testability, Layout, Routing, 
Logic Simulation, Circuit Simulation, Timing Verification, Application Specific Devices, 
Microarchitecture, Regional/Global Perspectives, Economic Issues, and India’s ASIC 
design environment. 

PAPERS: Six (6) copies of previously unpublished papers should reach either of the 
program chairs by July 15, 1990. A manuscript should clearly state the originality of its 
contribution, significant results and applications. It should not exceed ten double-spaced 
pages including figures and references. The authors should identify the presenting 
author and include the complete address, telephone and/or FAX numbers and, when 
possible, email address. The papers will be selected through a review process and the 
authors will be notified of acceptance by September 15, 1990. Camera-ready 
manuscripts (limited to s/x book pages) will be due on November 15, 1990. 

TUTORIALS: The symposium has run a highly successful tutorials program in the past. 
Four full-day tutorials are being planned. Although the final choice of topics is open at 
this time, speakers on analog VLSI design, design for testability, hardware description 
languages, and synthesis, are sought. Proposals may be submitted to either of the 
tutorials chairs. A tutorial may include a software demonstration. 

EXHIBITS: The symposium provides a unique opportunity for CAD/CAE systems ven¬ 
dors to display their products. Since the available space may be limited, those 
interested should contact the exhibits chair as soon as possible. 

Contact publicity chairs for any other information concerning the symposium. 








Cognitiva 90, Nov. 20-23, Madrid. 
Sponsor: AFCET. Contact Cognitiva 90, 
c/o AFCET, 156 Bd Pereire, 75017 Paris, 
France, phone 33 (01) 47-66-24-19. 

IEEE 1990 Conf. on Software Mainte- 
nance, Nov. 26-29, San Diego, Calif. 
Contact Thomas M. Pigoski, USN, NSGD 
Pensacola, Corry Station, Pensacola, FL 
32511, phone (904) 452-6399. 


croarchitecture, Nov. 27-29, Orlando, Fla. 
Cosponsor: ACM. Contact Chris Papachris- 
tou. Case Western Reserve Univ., Computer 
Engineering and Science Dept., Cleveland, 
OH 44106, phone (216) 368-5277, e-mail 
captffialpha.ces.cwru.edu. 


December 1990 


Symp. on Uncertainty and 
Analysis: Fuzzy Reasoning, Probabil¬ 
istic Methods, and Risk Management, Dec. 
3-5, College Park, Md. Sponsors: Univ. of 
Maryland et al. Contact Bilal M. Ayyub, Civil 
Engineering Dept., Univ. of Maryland, Col¬ 
lege Park, MD 20742. 


OTy ACM SIGSoft 90, Fourth Symp. on 
Software Development Environ¬ 
ments, Dec. 3-5, Irvine, Calif. Sponsor: ACM. 
Contact Dewayne E. Perry, AT&T Bell Labs, 
600 Mountain Ave., Murray Hill, NJ 07974, 
phone (201) 582-2529. 

Sixth Computer Security Applica- 
tions Conf., Dec. 3-7, Tucson, Ariz. 
Sponsors: American Society for Industrial Se¬ 
curity et al. Contact Marshall D. Abrams, Mitre 
Corp., 7525 Colshire Dr., M/S Z269, McLean, 
VA 22101, phone (703) 883-6938, e-mail 
abrams@mitre.org. 

ICCV 90, Third Int’l Conf. on Com- 
puter Vision, Dec. 4-7, Osaka. Japan. 
Contact ICCV 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington. 
DC 20036-1903, phone (202) 371-1013. 

nth Real-Time Systems Symp., Dec. 
5-7, Orlando, Fla. Sponsor: IEEE Com¬ 
puter Society Technical Committee on Real- 
Time Computing. Contact Doug Locke, IBM 
— MS 409, Systems Integration Div., 6600 


u CASE 90, Fourth Int’l Workshop on 
' Computer-Aided Software Engineer¬ 


ing, Dee. 5-8, Irvine, Calif. Contact Elliott J. 
Chikofsky, Radius Systems, 75 Lexington St., 
Burlington, MA 01803, phone (617) 494- 
8200. 

San Diego Workshop on Volume Visu- 
alization, Dec. 10-11, La Jolla, Calif. 
Cosponsor: ACM. Contact T. Todd Elvins, 
SDSC, Box 85608, San Diego. CA 92038, 
phone (619) 534-5128. 

Second IEEE Symp. on Parallel and 
Distributed Processing, Dec. 10-12, 
Dallas. Sponsor: Dallas Section of the IEEE 
Computer Society. Contact Behrooz Shirazi, 
Computer Science and Engineering Dept., 
Southern Methodist Univ., Dallas, TX 75275, 
phone (214) 692-2874, e-mail shirazi% 
smu.uucp@uunet.uu.net. 

1990 IEEE Workshop on Languages 
and Architectures for Automation, 
Dec. 19-21, Honolulu, Hawaii. Sponsors: Pa¬ 
cific Int’l Center for High Technology Re¬ 
search et al. Contact D.Y.Y. Yun, Univ. of Ha¬ 
waii, 711 Kapiolani Blvd., Suite 200, Hon¬ 
olulu, HI 96813-5249, phone (808) 539-1532, 
fax (808) 941-1399; or Shi-Kuo Chang, 322 
Alumni Hall, Univ. of Pittsburgh, Pittsburgh, 
PA 15260, phone (412) 624-8493, fax (412) 
624-8465, e-mail chang@vax.cs.pitt.edu. 


THE SECOND IEEE SYMPOSIUM ON PARALLEL AND DISTRIBUTED PROCESSING 
DECEMBER 9-13,1990 - DALLAS, TEXAS 


Co-Sponsors: IEEE Computer Society and lEEE-CS Dallas Chapter 


General Chairs: 

Prasenjit Biswas 
Ali R. Hurson 


Program 

Committee: 

James Abello 
Dharma Agrawal 
Said Bettayeb 
Laxmi Bhuyan 
Bill Carroll 
Bethany Chan 
Paul Fisher 
Krishna Kavi 
David Matula 
Milan Milenkovic 
Rischiyur S. Nikhil 
Girish Pathak 
V. Ramachandran 
Mary Lu Soffa 
loannis Tollis 
David Y.Y. Yun 


SUBMISSION: This symposium provides a forum for the presentation and exchange of 
current work on a wide variety of topics in parallel and distributed processing. Both long and 
short papers are considered. Long papers will be refereed with respect to their quality and 
originality. The manuscripts must be typed double-spaced, must include an abstract of about 
200 words, and should not be longer than 5,000 words. Efforts are under way to secure a 
special issue of a reputable journal based on selected papers from this symposium. All 
accepted papers will be published in the symposium proceedings. Please submit 7 copies of 
the complete paper (for long papers) or 7 copies of a 300-word abstract (for short papers) to 
either Co-Program Chairs: 


Behrooz Shirazi 
Department of Computer Science 
Southern Methodist University 
6425 Airline Road 
Dallas, TX 75205-2337 
(214)692-2874 


Hal Sudborough 

Computer Science Program, MP 31 
University of Texas at Dallas 
2601 N. Floyd Road 
Richardson, TX 75083-0688 
(214) 690-2184 


Deadline for paper submissions is May 1,1990. Notifications will be mailed by August 10, 1990. 
Final camera-ready papers are due September 10, 1990. 


Tutorial and Panel Proposals: Please submit your proposals including the title, abstract, your 
biography, and a list of panelists to the Tutorial and Panel Chair by May 1,1990: 


Margaret Eich 

Department of Computer Science, Southern Methodist University 
6425 Airline Road 
Dallas, TX 75205-2337 
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IEEE COMPUTER SOCIETY 
Membership / Subscription Application 



BENEFiTS 



Computer 

Computer comes automatically 
with membership. Written, 
reviewed, and refereed by 
experts, it features survey and 
tutorial articles covering the 
entire computer field, and 
departments such as new 
products, new product reviews, 
standards, and a reader forum 
calied “The Open Channel." 
(monthly). 


Technical Committees 

Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate In the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books 

Receive discounts of up to 50% on over 600 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and design automation. Over 60 new titles 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 
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SCnGdUlB Of re©S jo subscribe: see item 4. 

Membership dues and periodical subscriptions are annualized to, and expire on, 
December 31. Choose full- or half-year rate schedules depending on date of 
receipt by the Computer Society as indicated below. Half Year Full Year 


ar 1-Aug 31 Sept 1-Feb 28 


I don’t belong to the IEEE and I want 
to join just the Computer Society 


□ $23.50 □ $47.00 


\ I don’t beiong to the IEEE and I want 
■ to join both the Computer Society and the IEEE* 

I reside in Region 1-6 (United States). □ $47.50 □ $95.00 

I reside in Region 7 (Canada). □ $43.50 □ $87.00 

lresideinRegion8(Europe, Africa, orthe Middle East) □ $43.00 □ $86.00 

I reside in Region 9 (Latin America). □ $39.50 □ $79.00 

I reside in Region 10 (Asia and Pacific). □ $38.50 □ $77.00 

*ACM members who join both IEEE and the Computer Society may deduct $5 off the 
full-year rate; $2.50 Off the half-year rate. 


I I already belong to the IEEE and 1 want 
to join the Computer Society. 

IEEE Member Number 


□ $9.00 □$18.00 


4 OPTIONAL PERIODICALS for new or current members 

issues per year 

IEEE Computer Graphics and Applications (3061) 6 

IEEE Design and Test (3111) .6 

IEEE Expert (3151) . . .6 

IEEE Micro (3071) . ..6 

IEEE Software (3121) . . 6 

Transactions on Computers (1161) .12 

Transactions on Knowledge and 

Data Engineering (1471). . 4 

Transactions on Parallel and 

Distributed Systems (1501) .4 

Transactions on Pattern Anaysis and 


□ $10.00 

□ $20.00 

□ $10.50 

□ $21.00 

□ $ 9.00 

□ $18.00 

□ $ 9.50 

□ $19.00 

□ $10.00 

□ $20.00 

□ $10.00 

□ $20.00 

□ $ 5.00 

□ $10.00 
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□ $11.00 
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PRICES EXPIRE 12/31/90 
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>e governed by IEEE's and the society’s constitutions, bylaws, and statements of 


MAILING ADDRESS 


Return to: IEEE Computer Society, 10662 Los Vaqueros Circle, P.O. Box 3014 Los Alamitos, CA 90720-1264 USA. pco 

Residents of Europe mall to: IEEE Computer Society, 13, Avenue de I’Aquilon, B-1200, Brussels, BELGIUM. 

Asian / Pacific residents mail to: IEEE Computer Society, Ooshima Building, 2-19-1 Minami-Aoyama, Minato-ku, Tokyo 107 JAPAN. 
















































CAREER OPPORTUNITIES 


RATES: $12.00 per line, (ten lines mini¬ 
mum). Average five typeset words per 
line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified Adver¬ 
tising, COMPUTER Magazine, 10662 
Los Vaqueros Circle, PO Box 3014, 
Los Alamitos, CA 90720-1264; (714) 
821-8380; fax (714) 821-4010. 


UNIVERSITY OF WISCONSIN- 
MADISON 
Faculty Positions 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
tenure and tenure-track positions. A Ph.D. 
degree is required, and successful candi¬ 
dates are expected to participate in both 
teaching and research activities. Applicants 
in all areas of computer engineering are in¬ 
vited to apply, but the following areas are of 
special interest: computer architecture, com¬ 
puter networks, VLSI and computer-aided 
design, microprocessor and minicomputer 
applications, real-time control and instru¬ 
mentation applications, and engineering ap¬ 
plications of artificial intelligence. Rank and 
salary will be commensurate with qualifica¬ 
tions and experience. Send resume and 
names of three references to J. Leon 
Shohet, Chairman, Department of Electrical 
and Computer Engineering, University of 
Wisconsin-Madison, 1415 Johnson Drive, 
Madison, WI 53706, an equal opportunity/ 
affirmative action employer. 


COLLEGE OF THE REDWOODS 
Computer Information 
Systems Instructor 

Picture yourself living in beautiful North¬ 
ern California and teaching in a relaxing and 
attractive atmosphere. College of the Red¬ 
woods District extends from the Mendocino 
Coast area (190 miles north of San Fran¬ 
cisco), to the Oregon border. 

A dedicated faculty guarantees high- 
quality instruction to students pursuing the 
Associate in Arts or Associate in Science 
degrees, completing academic transfer re¬ 
quirements, or seeking occupational train¬ 
ing. Modern facilities and annually updated 
equipment provide instructors with state-of- 
the-art teaching tools and assure well equip¬ 
ped programs for both the beginning and ad¬ 
vanced student. 

The position is full-time, tenure track at the 
Eureka campus and will begin August 15, 
1990 (30 hr/wk, 10 mo/yr). Will be respon¬ 
sible to instruct and assist small group and/or 
individual instruction to students in a variety 
of computer languages and applications 
within a computer laboratory environment. 
Final filing date April 6, 1990. For further in¬ 
formation and to obtain a CR application, 
contact the Personnel Office, College of 
the Redwoods, 7351 Tompkins Hill Road, 
Eureka, CA 95501. 707-445-6850. EOE 


VANDERBILT UNIVERSITY 
Department of Electrical Engineering 

Applications for research positions at the 
rank of Research Assistant Professor are so¬ 
licited from highly qualified individuals with a 
strong entrepreneurial spirit, and commit¬ 
ment to sponsored research and teaching. 
Candidates should have demonstrated 
abilities and interest in the following fields: ar¬ 
tificial intelligence, parallel processing and 
real-time systems. Applicants must have a 
Ph.D. in Electrical or Computer Engineer¬ 
ing. Please submit a detailed resume in¬ 
cluding a statement of professional interest 
to: Prof. George E. Cook, Chairman, 
Search Committee, Robotics and Automa¬ 
tion Research Group, Department of Elec¬ 
trical Engineering, Vanderbilt University, 
Box 1824, Station B, Nashville, TN 37235, 

EOAA Employer. 


SEATTLE UNIVERSITY 
Chair, Department of Computer 
Science and Software Engineering 

Seattle University invites applications for 
the position of Chair of the Department of 
Computer Science and Software Engineer¬ 
ing. A Ph.D. in Computer Science or a re¬ 
lated field is required. Excellence in both 
teaching and scholarship, in computer sci¬ 
ence or software engineering, is essential. 
The Chair is charged with overall leadership 
of the Department, including curricular re¬ 
newal, faculty recruitment and development, 
student affairs, and financial management. 

The Department has 10 faculty members 
and over 200 students, split evenly between 
the undergraduate programs in Computer 
Science and an innovative Master’s program 
in Software Engineering. Faculty are pro¬ 
vided with individual Macintosh II’s (or com¬ 
parable hardware) and also have access to 
Seattle University’s Encore Multimax com¬ 
puter, a fast time-sharing system with parallel 
processing capabilities running Berkeley 
Unix. This summer we will join the Internet. 

Founded in 1891, Seattle University offers 
excellent science and engineering education, 
grounded in the Jesuit tradition of career- 
oriented education with a strong liberal arts 
base. We are a multicultural campus in an ur¬ 
ban setting intent upon increasing the diver¬ 
sity of our faculty. Women and minority can¬ 
didates are strongly encouraged to apply. 
Located in a beautiful setting of water and 
mountains, Seattle offers all the amenities of 
a large city, yet is close to skiing, hiking, and 
the many other recreational activities avail¬ 
able in the Pacific Northwest. 

All applications should include a summary 
of professional education and experience, 
along with three letters of recommendation; 
send applications to Dr. Ric Frankel, Depart¬ 
ment of Computer Science and Software 
Engineering, Seattle University, Seattle, WA 
98122. Reviews of all candidates will begin 
on May 1, 1990. Applications will continue 
to be accepted until the positions are filled. 


THE UNIVERSITY OF GRONINGEN 
THE NETHERLANDS 

Department of Computing Science 
Chairperson / Professor 
(vacancy number; 900315) 

Applications arc invited for the post of 
Chair of the Department of Computing Sci¬ 
ence. There is also the possibility that a 
second professorial position may become 
available within the near future about which 
preliminary enquiries are welcomed. Can¬ 
didates should possess a broad knowledge of 
computing science and a proven record of 
outstanding research ability in their own 
specialization. Good teaching capabilities 
and the ability to lead and direct the research 
of others are also required. The department 
is responsible for the degree of Computing 
Science as well as some service courses. The 
current research interests of the department 
are in the following fields: theory of com¬ 
puting, mathematics of programming, paral¬ 
lelism and concurrency, systems software 
and applied computing. 

Further information concerning the posi¬ 
tion can be obtained by writing to or phoning 
Prof. R.C. Backhouse, Department of Com¬ 
puting Science, University of Groningen, 
P.O. Box 800, 9700 AV GRONINGEN 
(email: roland@cs.rug.nl, telephone 
0113150 633939). Applications, together 
with a curriculum vitae, a list of publications 
and names plus telephone numbers of three 
referees, and three letters of reference, 
should be sent within four weeks after 
publication of this advertisement to the Head 
of the Personnel Department, University of 
Groningen, P.O. Box 72, 9700 AB Gron¬ 
ingen (the Netherlands). The University of 
Groningen is an equal opportunity employer 
and actively encourages female applicants. 


THE MEDICAL UNIVERSITY 
OF SOUTH CAROLINA 

Academic Teaching & Research position 
in Biomedical System Science at The Medi¬ 
cal University of South Carolina, Teach and 
conduct research in Computer Systems, 
Signal Analysis, Image Processing, Time 
Series, Stochastic Processes, Linear and non 
Linear Systems. Strong research record 
(publications) in knowledge-based image 
processing/segmentation required. Must 
have Ph.D. in Electrical Engineering. Ex¬ 
perience requirements: SUN (UNIX- 
SUNOS, SUNWINDOW), MACII, IBMPC 
(MSDOS), VAX/VMS, instrumentation 
and hardware interface for Signal/Image 
Processing (two years); Experimental Design 
and Data Analysis using Al-based techni¬ 
ques (one year); C, PASCAL, LISP, PRO¬ 
LOG, FORTRAN, and ASM Languages. 
Forty hour week, 8:30 a.m. to 5 p.m, 
$41,600per annum. Send curriculum vitae, 
reprints and three references to John 
Isehower, Job Order 938251, S.C. Employ¬ 
ment Security Commission, P.O. Drawer N, 
Charleston, SC 29402, 
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TRINITY COLLEGE 
Computer Science Faculty 

Trinity College is establishing a Depart¬ 
ment of Computer Science and is seeking 
candidates at any level for a teiiure track 
position starting in August 1990. The success¬ 
ful candidate will join two other computer 
science faculty in the continued develop¬ 
ment of the computer science major which 
was begun in 1985 and is presently offered 
through the Department of Engineering and 
Computer Science. 

Candidates must have a Computer Sci¬ 
ence Ph.D., a strong commitment to excel¬ 
lence in undergraduate teaching, a willing¬ 
ness and ability to participate in the continued 
development of a strong liberal arts com¬ 
puter science major and the potential to pur¬ 
sue an active research program. Applicants 
in all areas of computer science will be 
considered. 

Trinity College is a selective liberal arts 
college with a strong commitment to the sci¬ 
ences. In addition to computer science, the 
College offers majors in engineering, mathe¬ 
matics, chemistry, biochemistry, physics, bi¬ 
ology and psychobiology. The College’s aca¬ 
demic computing facilities include a VAX 
8350, a network of Sun 3/50 and 3/60 
workstations and numerous personal com¬ 
puters. Trinity College is an equal opportuni¬ 
ty/affirmative action employer, and has a 
primary goal of increasing the number of 
women and minority faculty in the sciences. 
Please send application letter, vita and letters 
of reference to Professor Ralph Walde, 
Department of Engineering and Computer 
Science, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin immediately and the search will remain 
open until the position is filled. 


GEORGIA INSTITUTE OF 
TECHNOLOGY 
School of Information and 
Computer Science 

The School of Information and Computer 
Science, soon to be incorporated in a newly 
created College of Computing, invites appli¬ 
cations for faculty positions at all levels, al¬ 
though preference will be given to applicants 
with several years of experience since the 
completion of a Ph.D. Aplicants should have 
a commitment to teaching and a record of 
outstanding research accomplishments. 

The School seeks applicants to strengthen 
its programs in all areas of computer science, 
although we have special interest in candi¬ 
dates in the areas of networking and tele¬ 
communications, software engineering, 
human-computer interaction, scientific com¬ 
puting and realtime computing. Very com¬ 
petitive salaries are offered. 

The School has 32 faculty members and 
anticipates further growth. Its educational ac¬ 
tivities include an undergraduate program 
accredited by the Computing Sciences Ac¬ 
creditation Board, Inc., a Masters program 
with 100 students, and a Ph.D. program 
with over 90 students. 

The School is in the third year of a five 
year Coordinated Experimental Research 
grant from the National Science Foundation. 
This grant is funding acquisition of hardware 


and design and development of software to 
support parallel and distributed computing. 
Current equipment includes a large number 
of SUN Unix workstations, a 32-node BBN 
Butterfly multiprocessor, a 10-node Sequent 
Symmetry multiprocessor, and other special¬ 
ized equipment. 

Georgia Tech is located in Atlanta, which 
has a mild sunbelt climate. Atlanta is the 
center of commerce in the Southeast, offer¬ 
ing a diverse economy, good cultural and 
recreational opportunities, extremely attrac¬ 
tive residential neighborhoods, and afford¬ 
able housing. 

Candidates should send complete resumes 
and names of at least three references to: 
Professor William Appelbe, Faculty Search 
Committee Chairman, School of Informa¬ 
tion and Computer Science, Georgia Insti¬ 
tute of Technology, Atlanta, GA 30332 
(404) 894-6187, internet mail address: bill® 
gatech.edu. 


UNIVERSITY OF VERMONT 
Visiting Faculty Positions 
in Computer Science 

The Department of Computer Science 
and Electrical Engineering invites applica¬ 
tions for up to two visiting faculty openings in 
Computer Science, commencing Septem¬ 
ber, 1990. A doctorate in Computer Sci¬ 
ence, or the equivalent is required. The level 
of assistant or associate professor will be 
dependent upon the candidates’ qualifica¬ 
tions. Responsibilities, in addition to re¬ 
search, include teaching in mainstream com¬ 
puter science at both the undergraduate and 
graduate level in two or more of the following 
areas: operating systems, programming lan¬ 
guages, database systems, computational 
complexity and algorithm theory, theory of 
:omputation, as well as the presentation of 
an advanced graduate course or seminar. 
Applications will be accepted until the posi¬ 
tions are filled. Please submit a resume, in¬ 
cluding teaching experience, a publication 
list, and the names, addresses, and phone 
numbers of three references to: Dr. Kenneth 
Golden, Chairperson; University of Ver¬ 
mont; Department of Computer Science 
and Electrical Engineering; Votey Building; 
Burlington, VT 05405; (802) 656-3330. In¬ 
ternet & CSnet: c!ssearch@uvm.edu;USE- 
NET: . . .uunet!uvm-gen!cssearch;BITNET: 
cssearch@uvm-gen.uvm.edu. The Univer¬ 
sity of Vermont is an Affirmative Action 
Equal Opportunity Employer and encour¬ 
ages applications from women and members 
of minority groups. 


SOFTWARE ENGINEERING- 
RESEARCH SCIENTIST 

Design and implement system to auto¬ 
mate tasks of reverse and forward software 
engineering. Develop key algorithmic inno¬ 
vations. Ph.D. Computer Science required. 
Knowledge in MODEL System, Ada, C 
PL/1, VM/CMS, Digital VAX/VMS and 
Unix required. $49,200/year. Send resume 
or c.v. to: Phila. Job Bank 444 N. 3rd St., 
3rd FI. Phila, PA 19123. Refer to job order 
number 4304943. Proof of legal right to 
work in U.S. required. 


UNIVERSITY OF HOUSTON 

Applications are invited for tenure track 
faculty positions in the Department of Com¬ 
puter Science starting September 1990. 
Areas of special interest include but not 
limited to artificial intelligence, computer ar¬ 
chitecture, computer graphics, computer 
networks, operating systems, programming 
languages and software engineering. Rank 
and salary are open and competitive. The 
Department is interested in expanding its 
research program and particularly welcome 
applicants for senior positions. Applicants 
should have a Ph.D. in Computer Science or 
a closely related area, and a strong commit¬ 
ment to research and teaching. Candidates 
for senior positions should also have a 
distinguished research record. The Depart¬ 
ment offers Ph.D., M.S., and B.S. in Com¬ 
puter Science. Departmental research facili¬ 
ties include a network of SUN Workstations, 
VAX 11/780 and VAX 11/730’s, a net¬ 
work of AT -h T 3B20 and 3B2’s and access 
to other computing facilities in the University 
Computer Center as well as supercomputers 
via remote access terminals. Send resume 
and names of professional references to Dr. 
Willis King, Chairman, Department of Com¬ 
puter Science, University of Houston, 
Houston, Texas 77204-3475. An Equal Op¬ 
portunity/Affirmative Action Employer. 


NAVAL POSTGRADUATE SCHOOL 

The Computer Science Department invites 
applications for faculty positions at all levels. 
Our primary interests are in the areas of 
operating systems and programming lan¬ 
guages. Our secondary interests are in the 
areas of visual data processing, graphics, 
and computer architecture (especially real¬ 
time and parallel-processing aspects of the 
three). Applicants should have a Ph.D. in 
Computer Science or a closely related field 
and be committed to high-quality teaching 
and research. Senior applicants must have 
distinguished research records. Appoint¬ 
ments can begin at any time. 

The Department offers M.S. and Ph.D. 
degrees in computer science, but no under¬ 
graduate degrees. Currently, 110 students 
are enrolled in the M.S. program and five in 
the Ph.D. program. Students are military of¬ 
ficers or civilian employees of the Depart¬ 
ment of Defense and are fully supported by 
their sponsoring organization during their 
studies. Departmental facilities (supported 
by eight full-time computer professionals) in¬ 
clude six instructional and research labora¬ 
tories with extensive state-of-the-art equip¬ 
ment. Faculty normally teach for two quarters 
and perform research for two quarters per 
year. The Monterey-Carmel area provides a 
pleasant coastal climate and easy access to 
Silicon Valley companies. 

Send a detailed resume, an abstract of 
your best recent research, and letters of ref- 

Faculty Search Committee 
Computer Science Department, Code 52 
Naval Postgraduate School 
Monterey, CA 93943 
Telephone (408) 646-2449 
An Equal Opportunity/Affirmative Action 
Employer 
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TRINITY COLLEGE 

The Department of Engineering and Com¬ 
puter Science announces a tenure-track 
position, pending approval, in the field of 
Mechanical Engineering. It, therefore, in¬ 
vites applications from outstanding candi¬ 
dates for a position at the Assistant or 
Associate Professor-level commencing Sep¬ 
tember, 1990, in the areas of THERMO¬ 
DYNAMICS/HEAT TRANSFER or ROBOT¬ 
ICS/CONTROLS. Experimental background 
highly desirable. The position involves grad¬ 
uate and undergraduate instruction and 
research, and a doctoral degree is a prereq¬ 
uisite. We are interested in receiving applica¬ 
tions from women and minorities. Trinity 
College is an equal opportunity/affirmative 
action employer. Please send resume to Pro¬ 
fessor Joseph D. Bronzino, Chairman, ECS 
Department, Trinity College, Hartford, CT 
06106. Consideration of applications will 
begin immediately and the search will remain 
open until the position is filled. 


MINITAB, INC. 

Minitab, Inc., a leader in the development 
of statistical software, offers two career op¬ 
portunities: 

PROGRAM DEVELOPMENT MANAGER 

Responsibilities include: Manage depart¬ 
ment, implement new Minitab capabilities, 
produce in-house conversions, and maintain 
software. Qualifications: MS or Ph.D. in 
Computer Science or a related technical 
field, 2 years experience managing software 
development, and 4 years experience in 
systems programming and analysis of scien¬ 
tific applications. Development experience 
on varied operating systems in Fortran or C 
and software project management also re¬ 
quired. Desired: development experience 
on IBM VM/CMS, development of graphi¬ 
cal user interface, knowledge of numerical 
methods, and experience in programming 
statistical applications. 

STATISTICAL SOFTWARE ENGINEER 

Responsibilities include: Design, program, 
and test mathematical/statistical applica¬ 
tions; maintain program; provide technical 
leadership on statistical, numerical, and 
algorithmic issues; and convert Minitab for 
some platform (preferably IBM VM/CMS). 
Qualifications: 2 years experience develop¬ 
ing mathematical/scientific software in a 
commercial setting, MS or Ph.D, in statistics 
or equivalent with knowledge of numerical 
methods and experience in implementing 
them, and experience developing large For¬ 
tran applications (C experience a plus). 
Development experience on IBM VM/CMS 
and on Unix is highly desirable. 

Minitab, Inc. provides an excellent salary 
and benefits package in an attractive work 
environment. Located in the mountains of 
central PA adjacent to Penn State Universi¬ 
ty, we offer outdoor recreation, an intellec¬ 
tual climate, and many cultural and athletic 

For confidential consideration, send your 
resume and salary requirements to: 

Glen Pike 
Minitab, Inc. 

3081 Enterprise Drive 
State College, PA 16801 
E.O.E. 


MILLERSVILLE UNIVERSITY 
Mathematics & Computer 
Science Department 

Applications are invited for a full-time 
tenure-track position in Computer Science 
beginning Fall, 1990. Candidates should 
have a Ph.D. in C.S. or equivalent field; 
A.B.D. with commitment to earning a doc¬ 
torate will be considered. Candidates should 
be qualified to teach upper-level under¬ 
graduate computer science courses. Prefer¬ 
ence given to those whose qualifications in¬ 
clude SOFTWARE ENGINEERING and 
SYSTEMS ANALYSIS. Strong verbal skills 
are a must and strong teaching experience is 
preferred. Teaching loads are 24 semester 
hours per year; released time for research is 
available. Appointment will be made at 
Assistant or Associate Professor rank de¬ 
pending on qualifications and experience. 

Seven full-time Computer Scientists form 
an independent unit within the combined 
department, offering a B.S. in Computer 
Science to 300 students. Formation of a 
separate C.S. department is expected for 
Fall, 1990. Faculty research interests include 
computer vision, artificial intelligence, in¬ 
telligent tutoring systems, and database 
management. The faculty has been success¬ 
ful in soliciting grant money. 

Computer Systems include: Micro VAX 
3600, three Tektronix 4319 graphics work¬ 
stations, MicroVAX II, and peripherals for 
graphics, computer vision, and robotics, all 
exclusively for C.S. C.S. also has access to a 
VAX-11/750, IBM 4361, and a lab with 25 
MACINTOSH SE’s. The University main¬ 
tains numerous other computer labs for non- 
C.S. Each C.S. faculty is provided with a 
MAC SE in his/her office with connection to 
a laser printer. 

Send vita, copies of transcripts, and three 
letters of recommendation (at least one of 
which attests to your teaching effectiveness) 
to: Thomas Mertz, Search Committee Chair¬ 
person, Dept, of Math & Computer Science 
IEO490, MILLERSVILLE UNIVERSITY, 
Millersville, PA 17551, Screening of appli¬ 
cants will begin immediately and will con¬ 
tinue until the position is filled. An Affir¬ 
mative Action/Equal Opportunity Employer. 


ACADEMIA SINICA 
Taiwan, Republic of China 
Institute of Information Science 

Applications are invited for research posi¬ 
tion in Institute of Information Science, Aca¬ 
demia Sinica. Ph.D. in computer or closely 
related fields required. Demonstratable re¬ 
search ability necessary. Applicants for 
senior positions must have proven research 
record. All fields in computer science are 
welcome. 

The Institute offers a good reseach en¬ 
vironment. No duty of teaching. Facilities in¬ 
clude 2 VAX’s, many SUN, IRIS, and E&S 
workstations, and an easily accessible ETA- 
lOQ supercomputer at Academia Sinica. 
Budget for a parallel machine is available this 

Interested people please send application 
to Dr. Y.S. Kuo, Acting Director, Institute of 
Information Science, Academia Sinica, Tai¬ 
pei, Taiwan 11529, Republic of China. 
FAX: (011-886-2) 782-4814. 


THE UNIVERSITY OF TENNESSEE 

Department of Computer Science 

Knoxville, Tennessee 37996-1301 

The Department of Computer Science in¬ 
vites applications for tenure-track positions at 
the rank of Professor beginning Spring 1990. 
A strong research record in the areas of com¬ 
puter graphics, networking, or operating sys¬ 
tems is sought but all major fields in computer 
science may be considered. Experience 
directing doctoral students is especially im¬ 
portant. Tenure-track positions for Associate 
and Assistant Professors are also open. Ap¬ 
plicants for Associate Professor should have 
a strong research record, preferably in the 
above-named areas; experience directing 
doctoral students is desirable. Applicants for 
Assistant Professor should have a strong in¬ 
terest in research, preferably in the above- 
named areas. Applicants for all positions 
should have a doctoral degree in computer 
science or a related area. 

Departmental SUN, IBM and DEC work¬ 
stations abound for students and faculty and 
are fully networked. Special systems support 
graphics and image analysis. The University 
operates an IBM 3090 and a large VAX 
cluster. CRAY, HYPERCUBE, SEQUENT 
and other machines are available via high 
speed link with Oak Ridge National 
Laboratory. 

You can respond to straight@utkvx.utk. 
edu. The mailing address is Department of 
Computer Science, 107 Ayres Hall, The 
University of Tennessee, Knoxville TN 
37996-1301. 

The University of Tennessee is an EEO/ 
AA/TITLE IX/SECTION 504 employer. 


COLORADO SCHOOL OF MINES 
Golden, Colorado 
Computer Scientist 

The Colorado School of Mines Depart¬ 
ment of Mathematics invites applications for 
a tenure-track faculty position in Computer 
Science. This program emphasizes software 
development, software systems, artificial in¬ 
telligence, languages, database manage¬ 
ment, and numerical computation. Speciali¬ 
zation in software engineering is desired but 
consideration will be given to applications 
with experience in all areas of program 
emphasis. 

Duties include teaching and graduate stu¬ 
dent research supervision. Applicants should 
demonstrate significant research accom¬ 
plishment or exceptional research promise 
and a commitment to excellence in teaching. 
Record of funded research should be docu¬ 
mented by applicants for a senior level posi¬ 
tion. A Doctorate in a computer-related field 
required. Departmental programs in mathe¬ 
matical and computer sciences. 

Applications will be accepted until such 
time as the position is filled. 

Send vita including publications and 
names of three (3) references to: 

COLORADO SCHOOL OF MINES 

Computer Science Search Committee 

PO Box 69 

Golden, CO 80401 

An Equal Employment/Affirmative Ac¬ 
tion Employer. Females and Minorities En¬ 
couraged to Apply. 
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POTSDAM COLLEGE 
Chair, Department of Computer and 
Information Sciences 

Applications are sought for the position of 
Chair of the Department of Computer and 
Information Sciences at Potsdam College of 
the State University of New York. 

The Department is one of seventeen in the 
School of Liberal Studies, the largest of the 
three schools of Potsdam College. Currently 
there are 10 full time faculty and 200 majors 
in the Department. 

Preference will be given to individuals 
possessing a Ph.D. in Computer Science 
though applicants with Ph.D.’s in closely 
related fields and substantial graduate 
preparation in computer science (at least a 
Master’s degree) will also be considered. 
Some industrial experience would be wel¬ 
come. Rank is negotiable, salary and fringe 
benefits are very competitive. Responsibili¬ 
ties are for the academic year. 

The successful candidate should have a 
clear vision of an undergraduate computer 
science program appropriate to a selective 
liberal arts college whose primary mission is 
teaching and should possess the leadership 
and administrative skills needed to make this 
vision a reality. A strong record of successful 
undergraduate teaching and active scholar¬ 
ship are expected. 

Applicants should provide a letter discuss¬ 
ing how their education and background 
have prepared them to fulfill the responsibili¬ 
ties of this position as described, a current 
resume, the names, addresses and telephone 
numbers of three to five references to: 

Dr. Richard J. Del Guidice 

Dean 

School of Liberal Studies 

Potsdam College 

Potsdam, NY 13676 

Deliberations will begin 15 April and con¬ 
tinue until the position is filled. Potsdam Col¬ 
lege actively seeks applications from women 
and minority candidates. 


WRIGHT STATE UNIVERSITY 

Department of Computer Science 
and Engineering 

Applicants are invited for tenure-track and 
visiting professors at all levels. Senior profes¬ 
sors are invited to apply for visiting and re¬ 
search positions. The successful candidate 
should have a PhD in computer science, 
computer engineering, or equivalent back¬ 
ground and have demonstrated forward 
looking and creative research. Further de¬ 
sired attributes include: capability to direct 
PhD candidates in computer science or com¬ 
puter engineering and the ability to acquire 
funds and/or direct research projects. All 
technical areas will be considered including: 
machine learning and neural networks, op¬ 
erating systems, programming languages 
and numerical methods. Rank and competi¬ 
tive salaries are determined by qualifications 
and experience. 

The university is located in a high technol¬ 
ogy environment among industrial/military 
research and development facilities including 
Wright-Patterson Air Force Base and NCR. 
Department strengths include a fully net¬ 
worked Unix environment of Sun worksta¬ 
tions, Cray access, graduate laboratories in 


AI, optical computing, neural networks, and 
robotics; established research programs; in¬ 
dustrial/military support; degree programs 
in both computer science and computer 
engineering, and a large graduate student 
population. 

Please submit a detailed resume including 
names of three references to: CSNET ad¬ 
dress: amcaulay@cs.wright.edu or Alastair 
D. McAulay, NCR Distinguished Professor 
and Chair, Department of Computer 
Science and Engineering, Wright State 
University, Dayton OH 45435. Reviewing 
for positions will begin February 15 and con¬ 
tinue monthly until positions are filled or until 
September 1, 1990. 

An equal opportunity/affirmative action 
employer. 


NORWICH UNIVERSITY 

Tenure Track position in the Department 
of Computer Science and Engineering start¬ 
ing July 1990. Rank and salary commensu¬ 
rate with experience. Ph.D. desired, but will 
consider Masters with significant experience. 
Recently unified Computer Science and 
Computer Engineering program. Resources 
include: VAX Cluster, MicroVax, AT&T 
3B2 400, VAX Stations and numerous PCs. 
New faculty member will be responsible for 
teaching courses in an undergraduate Com¬ 
puter Science curriculum and assisting in 
curriculum and laboratory development. Ex¬ 
pertise in any of the following areas desired: 
Computational Algorithms, Simulation, 
Operating Systems, Computer Graphics, 
Programming Languages, AI and Software 
Methodology. A strong commitment to 
undergraduate education is essential. Appli¬ 
cations will be accepted until the position is 
filled. Norwich University is located in an 
area of Central Vermont that offers small 
town or rural living with outstanding recrea¬ 
tional opportunities. Must be U.S. Citizen or 
Permanent Resident. Send resume and ref¬ 
erences to Dr. Michael C. Murphy, Head, 
Computer Science and Engineering Depart¬ 
ment, Norwich University, Northfield, Ver¬ 
mont 05663. EOE. Women and minorities 
encouraged to apply. 


SEATTLE UNIVERSITY 

Department of Computer Science 
and Software Engineering 

Seattle University invites applications for a 
tenure-track faculty position in the Depart¬ 
ment of Computer Science and Software 
Engineering at either the assistant professor 
or the associate professor level. A Ph.D. in 
Computer Science or a related field is re¬ 
quired. Excellence in both teaching and 
scholarship, in computer science or software 
engineering, is essential. 

The Department has 10 faculty members 
and over 200 students, split evenly between 
the undergraduate programs in Computer 
Science and an innovative Master’s program 
in Software Engineering, Faculty are pro¬ 
vided with individual Macintosh IPs (or com¬ 
parable hardware) and also have access to 
Seattle University’s Encore Multimax com¬ 
puter, a fast time-sharing system with parallel 
processing capabilities running Berkeley 


Unix. This summer we will join the Internet. 

Founded in 1891, Seattle Univeristy offers 
excellent science and engineering education, 
grounded in the Jesuit tradition of career- 
oriented education with a strong liberal arts 
base. We are a multicultural campus in an ur¬ 
ban setting intent upon increasing the diver¬ 
sity of our faculty. Women and minority can¬ 
didates are strongly encouraged to apply. 

Located in a beautiful setting of water and 
mountains, Seattle offers all the amenities of 
a large city, yet is close to skiing, hiking, and 
the many other recreational activities avail¬ 
able in the Pacific Northwest. 

All applications should include a summary 
of professional education and experience, 
along with three letters of recommendation; 
send applications to Chair, Faculty Search 
Committee, Department of Computer Sci¬ 
ence and Software Engineering, Seattle Uni¬ 
versity, Seattle, WA 98122. Reviews of all 
candidates will begin on May 1, 1990. Appli¬ 
cations will continue to be accepted until the 
positions are filled. 


UNIVERSITY OF WEST FLORIDA 
Division of Computer Science 

Applicants are invited for two tenure track 
positions in the Division of Computer Sci¬ 
ence. The successful candidates must hold a 
Ph.D. in Computer Science or closely re¬ 
lated field, and have a depth of knowledge in 
one or more of the following areas: construc¬ 
tivist approaches to AI and cognitive science, 
expert systems, knowledge acquisition, neu¬ 
ral nets, and image processing. 

The Division of Computer Science is an 
independent academic unit reporting to the 
Vice President of Academic Affairs. It offers 
a B.S. and M.S. degree in computer science 
and over the next few years will continue the 
development of its research and graduate 
programs including doctoral level work. Ex¬ 
tensive opportunities exist for local research 
involvement with the military and the 
medical communities. The Division currently 
enrolls about 650 undergraduate and 200 
graduate students. In addition, the Division 
houses the Institute for the Interdisciplinary 
Study of Human and Machine Cognition. 
The research environment includes a 
Solboume Series 4, Sun SPARCstations, 
Lisp machines, IBM mainframe, and 
numerous Macintosh computers. 

Competitive salaries combined with a very 
low cost of living enhance the excellent life¬ 
style available in northwest Florida. 

Vitae and letter of application should be 
sent to Dr, Theodore Elbert, Division Head, 
Computer Science, The University of West 
Florida, Pensacola, FL 32514. The positions 
will remain open until filled. UWF is an 
EO/AA institution. 


INDUSTRIAL POSITIONS FOR 
HARDWARE & SOFTWARE ENGRS 

Positions nationally. Fees paid by em¬ 
ployers. U.S. citizens or permanent residents. 
Degree plus minimum of two years applicable 
industrial experience. Call, write or fax, 
RSVP SERVICES, Dept. CM, Suite 614, 1 
Cherry Hill Mall, Cherry Hill, NJ 08002. 
800-222-0153, FAX: 609-667-2606, 
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BOOK REVIEWS 


Editor: Guy Johnson, Department of Information Technology, Rochester Institute of Technology, 1 Lomb Memorial Drive, Rochester, NY 14623 


Security Mechanisms for Computer Networks 

Sead Muftic (John Wiley & Sons, Somerset, N.J., 1989, 195 pp., $47.95) 


After the attack of the Internet worm 
last year, computer network security be¬ 
came front-page news in the nontechni¬ 
cal press. As more people use computers, 
more of them get involved with computer 
networking, even if only as a user, and the 
security of their work becomes of para¬ 
mount importance. 

Security Mechanisms for Computer 
Networks is an outgrowth of the Council 
of European Communities’ COST-11 
Ter Project on Security Mechanisms for 
Computer Networks. TTie project pro¬ 
duced a two-volume report on security 
mechanisms and the Open Systems Inter¬ 
connection network environment; this 
book is based on the first volume. 

The book consists of seven chapters of 
technical information, a section of refer¬ 
ences, and a closing section on future re¬ 
search directions. The first chapter is an 
introduction that offers an overview of 
the OSI network security architecture, 
defines terms, and separates the security 
issues into four classes: entity security 
(concerned with access to the system), 
communications security, database secu¬ 
rity, and process-control security. The 
author examines the classes and lists the 
basic services each performs. He then 
looks at network security architectures 
and breaks them down into their compo¬ 
nent pieces, describing both the active 
components (people and processes) and 
the passive components (databases and 
logs). The chapter concludes with a de¬ 
scription of the main problems for each of 
the classes. 

The rest of the book goes into more de¬ 
tail and presents algorithms for solving 
the problems. In Chapter 2, Muftic dis¬ 
cusses cryptography and key manage¬ 
ment, including both symmetric and 
asymmetric cryptography systems and 
giving the strengths and weaknesses of 
each. The examination of symmetric sys¬ 
tems includes a detailed discussion of the 
data-encryption standard (DES), and it 
concludes with introductions to the Brit¬ 
ish Telecom B-Crypt system and the 
Japanese FEAL-1 system. The discus¬ 
sion of asymmetric systems concentrates 


on the Rivest-Shamir-Adleman public 
key system, which is based on the relative 
difficulty of finding large prime numbers 
and factoring large numbers. The discus¬ 
sion of cryptography concludes with a 
brief look at current applications, con¬ 
centrating on digital signatures and se¬ 
cure distributed computing. The second 
half of the chapter concerns key manage¬ 
ment for cryptographic systems, includ¬ 
ing several algorithms for the distribu¬ 
tion of keys between two or more parties 
so that unauthorized parties cannot deter¬ 
mine the values of the keys. The auxiliary 
problem of authenticating the parties in¬ 
volved is also discussed. 

Chapter 3 then considers the problem 
of identifying users and authenticating 
their identification. Muftic discusses two 
types of authentication: peer-entity, in 
which the system authenticates the user, 
and mutual, in which both users in a trans¬ 
mission authenticate each other. Most 
users are familiar with passwords. Muftic 
takes the issue further and provides an 
expanded list of information that could be 
used to authenticate users, including per¬ 
sonal characteristics (such as physical 
characteristics and habits), usage pat¬ 
terns, and miscellaneous user knowl¬ 
edge. Finally, digital signatures are dis¬ 
cussed as a way to authenticate the sender 
of a message. The more sophisticated the 
mechanism, the harder it is for one user to 
impersonate another. On the other hand, 
sophisticated techniques also require 
more computer resources and effort to 
authenticate valid users. 

Chapter 4 goes into the area of access 
control mechanisms. Most of the infor¬ 
mation is what you would expect to get 
from a similar discussion in an operating 
systems course. The chapter concen¬ 
trates on the concept of the access matrix 
(and its subsets, the access list and the ca¬ 
pability list) and the principle of least ac¬ 
cess, which states that users should have 
no more access to an object than they need 
to perform their function. 

Chapter 5 examines data transfer in the 
network, concentrating on keeping a 
message’s contents both confidential and 


uncorrupted. The chapter includes a de¬ 
tailed discussion of various cipher meth¬ 
ods, contrasting their complexity with 
the protection they afford. In addition, 
the chapter discusses the problem of pas¬ 
sively analyzing the data stream as it 
flows through the network and considers 
how to minimize the information that can 
be deduced from network traffic patterns. 

Chapter 6 discusses database security, 
including dynamic protection against 
writing invalid data to the database and 
passive protection against data access 
that violates the defined access control. 
The ISO file-transfer access method is 
discussed here. 

Finally, Chapter 7 examines protec¬ 
tion for distributed systems. The very na¬ 
ture of distributed computing brings to¬ 
gether all the issues discussed earlier in 
the book and makes the interplay between 
the issues much more apparent. The is¬ 
sues are divided here between authoriza¬ 
tion to use the system and (once authori¬ 
zation has been granted) the ability to use 
system resources in a secure manner 
without interfering with other users or 
suffering from their interference. 

This text is a good reference for secu¬ 
rity issues. It clearly defines its terms and 
presents the algorithms needed to imple¬ 
ment (abstractly) the various security 
services, so that they can be applied to 
specific systems in the future. However, 
the fact that this is a theoretical text and 
not tied to any particular system is a 
weakness. People working with real sys¬ 
tems need to know how to handle real sys¬ 
tems. The issues in this book do affect real 
systems, but the book offers no way to 
gauge how much effort would be needed 
to increase security without adding so 
much overhead that the system is no 
longer usable. 

I recommend this book to security re¬ 
searchers or those involved in standards 
development that involves security is¬ 
sues. However, it won’t be of much use to 
system managers and users. 

Lome H. Schachter 

Bell Communications Research 
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Project Universe: An Experiment in High-Speed Computer Networking 

J.W. Burren and C.S. Cooper (Oxford University Press, New York, 1989, 290 pp., $49.95) 


Project Universe (universities’ ex- 
panded-ring and satellite experiment) 
was a collaborative effort to link seven 
geographically isolated local area net¬ 
works in Europe via the Orbital Test Sat¬ 
ellite. The project was conceived in 1980, 
and the network was constructed during 
1981-1983. Project Universe is a disap¬ 
pointing summary of the effort to unite 
LANs using methods characteristic of 
small local networks. 

The book discusses many of the soft¬ 
ware technologies used in Project Uni¬ 
verse and necessary in building any digi¬ 
tal communication network. It explains 
the time division multiple access method 
of dynamically allocating time slots in 
transmissions to and from the shared 
node (the satellite). The implementors 
used a single bandwidth and multiplexed 
data based on requested and granted res¬ 
ervations. Data channels were estab¬ 
lished by setting up lightweight virtual 
circuits — complete end-to-end channels 
similar to telephone system connections 
— or by transmitting single shot protocol 
or datagram packets. Some of the ma¬ 
chines on the network were diskless, re¬ 
quiring the use of boot servers, file serv¬ 
ers, and filing machines. The file servers 
and filing machines did not need to reside 
in the same computer or LAN. Global ad¬ 
dressing, which could be either system- 
wide or geographically global, was 
achieved via name servers in each LAN. 
Therefore, any process on any LAN could 
symbolically access any other system in 
the network, provided it had the correct 
security attributes. Whereas the name 
servers were physically located in the 
bridges (the computer links to the satel¬ 
lite), they could be located anywhere in a 
local network. 

The book’s most interesting coverage 
by far is of packetized voice and video 
image transmissions. Voice transmis¬ 
sions and playback used a silence trans¬ 
mission suppression to reduce traffic 
across the network and a strategy for 
tracking suppressed packets for playback 
reconstruction. The book covers several 
compression schemes for image trans¬ 
mission and compares coding schemes, 
predictive methods, and spatial transfor¬ 
mation methods. 

In a book such as this, it is difficult to 
separate its qualities from those of the 
project. The book gives a mere statement 
of the designs and implementations with 
little technical material and no allusions 
to whether the project satisfied its require¬ 
ments. By today’s standards, the imple¬ 
mentations are perhaps five years out of 


date. The book does a very good job of ref¬ 
erencing outside publications, but most 
of the references were published in the 
late 1970s and early 1980s. 

The book’s lack of specifications or an 
appraisal of performance against them 
might be a reflection of the project. The 
authors admit that almost every aspect of 


The book could actually 
be a negative influence to 
the aspiring engineering 
student, since many 
implementation decisions 
seem to have been made 
simply because they 
might work. 


the project had serious shortcomings. Al¬ 
though the participants were extremely 
knowledgeable about digital communi¬ 
cation networks, there might have been 
little in the way of specification from 
which to derive the necessary designs. 
This is a project management and disci- 
plinMy problem that might have been due 


Intel’s introduction of digital signal 
processing technology in 1979 perma¬ 
nently changed the field of real-time sig¬ 
nal processing. Digital Signal Processing 
Design gives the experienced electrical 
engineer or hardware designer the infor¬ 
mation needed to make the transition 
from standard analog to digital process¬ 
ing equipment design. This book is not 
for the engineer interested in the theoreti¬ 
cal basis of DSP design. On the other 
hand, it is an excellent independent- 
study or reference book for the engineer 
already schooled in the field’s fundamen¬ 
tal theoretical aspects. 

DSP technology could transform elec¬ 
tronic devices in the 1990s in much the 


to the pressures of meeting demonstra¬ 
tion dates and the necessity of using the 
satellite before its demise at the end of 
1983. Still, the book does not give enough 
information to judge the project’s success. 

Project Universe was demonstrated, 
although it was not an experiment in high¬ 
speed computer networking by today’s 
standards or even by those of the early 
1980s. The project reduced a 2-megabit/ 
second satellite channel to approxi¬ 
mately 0.270-megabit/second through¬ 
put to a single destination on a LAN ring 
under favorable conditions. If the experi¬ 
ment was to figure out how to use a satel¬ 
lite to link LANs efficiently, it could have 
been performed locally at considerable 
less expense using models, simulation, 
and implementations. Perhaps even 
higher performance interfaces could 
have been developed using models. 

The book’s cumbersome sentence 
structure and lack of technical depth or 
coverage of the development process 
make it inappropriate for either a course 
or a reference. The book could actually be 
a negative influence to the aspiring engi¬ 
neering student, since many implementa¬ 
tion decisions seem to have been made 
simply because they might work, with 
little thought given to system perform¬ 
ance or potential future impact. 

John E. Harkey 

Harkey Engineering 


same manner microprocessors did in the 
late 1970s and early 1980s. Where con¬ 
ventional data processing involves the 
manipulation of previously digitized 
data, most likely collected at some point 
in the past, DSP technology incorporates 
mathematically intensive algorithms 
into real-time operations that rely heav¬ 
ily on sampled data. Since the technology 
is relatively new, systems must remain 
flexible to allow for the inevitable algo¬ 
rithm modifications. 

With the impending rapid growth of the 
field, Bateman and Yates have filled the 
need for a good book describing the intri¬ 
cacies of the technology. The book is 
logically divided into three sections. The 


Digital Signal Processing Design 

Andrew Bateman and Warren Yates (Computer Science Press, Rockville, Md., 
1989, 385 pp., $59.95) 
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CASE: Concepts and Implementation 

Larry E. Towner (Intertext/McGraw-Hill, New York, 1989, 232 pp., $44.95) 


first covers DSP’s fundamental aspects 
and emphasizes the differences between 
it and analog technology. This section in¬ 
cludes brief overviews of binary arithme¬ 
tic and continuous and discrete signal 
processing theory, and a basic description 
of the DSP chip architecture. Of special 
interest is the chapter on mathematical 
theory, which gives the reader a feel for 
the complex mathematical operations. 

The second section covers the basics of 
data manipulation, signal processing, 
waveform generation, and digital filter¬ 
ing and transformation techniques. The 
section includes a veritable library of 
DSP algorithms, and many of the ex¬ 
amples are accompanied by actual im¬ 
plementation code based on Texas Instru¬ 
ments’ TMS320 series of DSP devices. 
Although such specific examples might 
at first seem to limit the book’s scope, 
they actually enhance the reader’s under¬ 
standing. 

The final section is devoted to hard¬ 
ware aspects of DSP design, including an 
overview of working with DSP periph¬ 
eral devices such as A/D convertors, pro¬ 
gram memory access, digital I/O, exter¬ 
nal memory addressing, and interrupts. 
The section also discusses high-level 
software support devices. By using these 
software simulation facilities and IBM 
PC-compatible or Digital Equipment 
Corporation VAX hardware, the practic¬ 
ing engineer will be well equipped to im¬ 
plement and test complex DSP algo¬ 
rithms. 

The book concludes with several ap¬ 
pendixes that cover such concepts as 
first- and second-order filter design, re¬ 
alization of a 512-point fast Fourier 
transform, derivations of signal correla¬ 
tion, spectral density functions, and coef¬ 
ficients from the autocorrelation func¬ 
tion estimate. 

Digital Signal Processing Design 
should be on the reading list of any elec¬ 
trical engineering or computer science 
course that covers DSP technology. 
Whereas many electrical engineering 
and computer science books are filled 
with esoteric theorems and proofs, this 
book is filled with excellent examples de¬ 
scribing solutions to real-world prob¬ 
lems. For those interested in the proofs 
behind the theories presented, many of 
the chapters end with several key refer¬ 
ences to the original literature. 

A lack of computer processing power 
severely limits many research and com¬ 
mercial endeavors. With the help of this 
book and the technology it describes, a 
skilled electrical engineer might be able 
to transform a doomed project into a spar¬ 
kling success. 

Dean F. Sittig 

Yale School of Medicine 


I was disappointed with this text. In¬ 
stead of a discussion of computer-aided 
software engineering and its various im¬ 
plementations, I found an introductory, 
step-by-step method for utilizing one 
CASE tool to develop database systems. 
Even toward this end, the author was only 
somewhat successful. While some parts 
of the book are good and might be of lim¬ 
ited benefit to someone in database man¬ 
agement design, the book’s deficiencies 
reduce its usefulness considerably. 

The book is divided into an introduc¬ 
tion and two sections. In the introduction, 
the author discusses CASE and provides 
some heuristics for the evaluation and se¬ 
lection of CASE tools. While the heuris¬ 
tics are sound, the discussion of CASE 
includes no information on different 
CASE concepts and implementations. 
Moreover, the author does not define 
CASE, and his discussion of the software 
life cycle is limited to a single illustra¬ 
tion. In short, the introduction is one of 
the text’s major shortcomings. 

The remaining two sections are of dif¬ 
fering worth; the second section is very 
good and could be of some use, but the 
first section is confusing and limited in 
scope. Given the inadequate introduc¬ 
tion, most readers would be highly dis¬ 
couraged before encountering the second 
section’s better qualities. 

In the first section, the author discusses 
the components of a CASE tool. Regret¬ 
tably, anyone looking for a general de¬ 
scription of CASE and its overall use in 
software engineering will need to look 
elsewhere. Only one CASE tool (Auto¬ 
mate Plus from Learmonth & Burchett 
Management Systems) and its accompa¬ 
nying methodology are discussed. In 
fact, it is sometimes difficult to deter¬ 
mine if this section is about CASE in gen¬ 
eral or Automate Plus in particular. 

This use of a single CASE tool and its 
methodology considerably influences 
the book’s content. For example, there is 


no discussion of testing or configuration 
management. There is also no discussion 
of parallel processes or other similar top¬ 
ics. The text appears to focus only on that 
which applies to Automate. Thus, it dis¬ 
cusses only one method for the specifica¬ 
tion, design, and initial coding of data¬ 
base management systems. 

In addition, the text’s vocabulary con¬ 
fused me, a problem compounded by the 
incomplete glossary. I had to reread the 
text several times to resolve ambiguities. 
This confusion was worsened by the au¬ 
thor’s occasional digressions into minu¬ 
tiae (such as when to change a pen on a 
printer) and his scant use of footnotes. 

The stronger second section clearly and 
concisely explains the efforts necessary 
to use a CASE methodology in software 
development. The examples are excel¬ 
lent, and I was impressed by the emphasis 
on designing a product based on the cus¬ 
tomer’s needs, not on other technical pro¬ 
gramming constraints. This perspective 
is the text’s major strength. The author 
clearly draws on his own experience and 
shows that software specification and de¬ 
sign are major activities, not simply pre¬ 
requisites to source code. The use of pro¬ 
cess inputs and outputs for each task and 
activity in the specification and design 
phases is excellent. 

I found the lack of a bibliography or 
reference list a bit disconcerting. Several 
excellent works on CASE have already 
been written, and the book would have 
been helped immensely by using any of 
these references to reinforce and substan¬ 
tiate the author’s ideas. 

Overall, the excellence of the second 
section is overshadowed by the book’s 
deficiencies. Hence, while the text might 
be of some value to a limited audience, I 
cannot recommend it. 


David W. Mutschler 

Naval Air Development Center 
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Computer-Aided Circuit Analysis Using Spice 


Walter Banzhaf (Prentice Hall, N.J., 

1989, 307 pp., $23.95) 

Spice is rapidly becoming the most 
widely used analog circuit simulator/ 
analyzer. There is, however, quite a 
learning curve before a user becomes 
truly proficient with it. As one who re¬ 
cently went through this frustration with 
only the user’s manual as a reference, I 
can testify to the need for a good Spice tu¬ 
torial. That is probably the main reason 
why I found Banzhaf s book so interest¬ 
ing and useful. It is fairly easy reading 
and requires only a modicum of circuit 
theory. The example problems are clear 
enough to be useful and, in many cases, 
technical enough to be interesting. 

In his introduction, Banzhaf suggests 
that the book is intended as an elementary 
text. From that standpoint, the mechanics 
of circuit and device modeling are cov¬ 
ered quite well, but if you are looking for 
extensive coverage of advanced subjects 
such as the modeling theory of complex 
devices, this is not the book for you. Mod¬ 
els of semiconductor devices, such as di¬ 
odes, transistors, and field-effect transis¬ 
tors, are covered in enough detail for the 
reader to know their purpose and use them 
in a circuit. However, the examples are 
generally “standard” functional device 


models that are not specific enough to be 
of much use in precision circuit simula¬ 
tions. Still, this does not detract from the 
text’s main function as a learning tool, 
not a modeler’s reference manual. 

The book contains 12 chapters and a 
section of solutions to problems in the 
text. There are also five logically organ¬ 
ized appendixes containing supplemen¬ 
tal data such as the specifics of simulator 
elements and data on Spice software. 

Since I am already familiar with Spice, 
I am using the text as a quick-reference 
manual. I am quite happy with it as such, 
but anyone who wants to learn the subject 
from scratch would be equally satisfied 
with it. 

The book begins with a short history of 
circuit modeling and a discussion of 
Spice in general, and then presents the 
circuit elements and their use. The more 
elementary devices, such as resistors and 
capacitors, are first presented together 
with some simple circuits as illustration. 
The discussion becomes more complex 
from chapter to chapter, dealing finally 
with the key to Spice usage, the modeling 
of complex active devices such as bipolar 
transistors and field-effect transistors. 

After discussing the more elementary 
device models (about midway through 
the text), the author discusses the types of 


analyses available. This seems like a 
logical place to address this subject, since 
the reader should now be ready to experi¬ 
ment with some circuits. SPICE offers 
several types of analyses (DC, transient, 
etc.) and several output formats, all of 
which are dealt with in rather good detail. 
Unfortunately, this information neces¬ 
sarily deals with a specific implementa¬ 
tion of the package, and many SPICE sys¬ 
tems are integrated into an interactive 
graphics environment with much more 
sophisticated capabilities than that de¬ 
scribed by the author. Readers using one 
of these systems might need to supple¬ 
ment this section with the user manuals. 

After this discussion, the book deals 
with progressively more complex cir¬ 
cuits and device. As I tried some of these 
on my system, I really began to enjoy my¬ 
self. It is interesting to take the examples, 
code them, and watch the results come 
out. I think this might be the main attrac¬ 
tion of the book: it is fun. I admit that it is 
written in a rather dry, matter-of-fact 
manner, but the topics are developed us¬ 
ing workable circuits, and that’s what 
makes the subject appealing. 


Ken Posse 
Hewlett-Packard 
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Codex is experiencing significant growth in its Network Management Development groups. We are hiring Software Development Engineers at 
all levels who can contribute to our state-of-the-art development efforts for the next generation of Network Management products. Contact us 
today if you are a degreed Software Engineer with at least 2 years’ experience in one or more of the following: 


Network Management Concepts and Applications 
Software Development in “C” or Object-Oriented Language 
Graphical Human Interface Techniques 
' Network Topology Management 
' Aegis or UNIX™ Operating Systems 
' Development of IBM/PC Applications Software Under MS 
Windows 

' Database Definition and/or Database Tool Development 
' Development and Maintenance of Standard Protocol Software 


Development of LAPB, X.25, ISO Network Layer, ISO Transport Layer 
Design, Implementation and Test of Reusable Device Management 
Software 

Structured Software Development 
Development of IBM Mainframe-Based Applications 
IBM Netview 

Development of Network Management Applications Software 
Use of Object-Oriented Techniques for Software Development 
' Use of Apollo Workstations 


These positions are at our Product Operations facility in Canton, MA, one of greater Boston’s most desirable suburbs. We are leM than an hour 
from world-class, cultural, medical and educational opportunities and close by all of New England’s four-season recreational facilities. Affordable 
housing is within commuting distance. 

Codex offers an excellent environment conducive to professional growth, competitive salaries and a comprehensive benefits 
package including profit sharing, 40IK and a generous pension plan. Our Advanced Sourcing concept allows you to add your 
resume to our database now and be reviewed against current and future openings based on your goals and requirements. Qualified 
candidates, please call 1-800-542-0606 or send a resume to the Advanced 
Sourcing Group at Codex Corporation, Dept. 13ECOMP490, 20 Cabot Blvd., 

MS M4-70, Mansfield, MA 02048. An Equal Opportunity/Affirmative Action 
Employer, M/F/V/H. 
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3167 throughput at 25 MHz is 5.5 Megawhetstones. 

mW3lS7/387 

This popular daughterboard (shown on the Number Smasher 
386/25) lets you plug a 3167 and an 80387 into a 386 system 
that has a single EMC socket. 


3167/4167 Numeric Performance 

3167/MCA NS 386/25 NS/486/25 

Megawhetstones 3.4 5.5 12.2 

Megawhetscales 1.6 3.1 9.9 


This XT/AT motherboard, 
replacement features a 25 
MHz 80486,4167 and a BURST 
BUS memory interface. The 
BURST BUS architecture is ideal 
for engineering, scientific and 
CAD/CAM applications. The NDP 
Fortran-486 driven numeric through¬ 
put running with the 4167 is 12 Meg¬ 
awhetstones and 10 Megawhetscales 
(see BYTE 1989 IBM issue). 


Our MCA Weitek card runs in the IBM Model 
70 and 80. At 20 MHz, its perfo 
to 3 times that of an 80387. 

NDP Fortran-486 and C-486 
are globally optimized main¬ 
frame compilers that have 
been fine tuned for the 
80486 and 4176. 
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World Leader in PC Numerics 

Corporate Headquarters: P.O. Box 79, Kingston, MA 02364 USA (508) 746-7341 
32 High St., Kingston-Upon-Thames, UK., 01-541-5466 
USA FAX 508-746-46 78 Italy 02-74.90.749 Holland 40 836455 Germany 069-75-2023 








